From xen-devel-bounces@lists.xenproject.org Thu Feb 01 00:06:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 00:06:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674184.1048957 (Exim 4.92) (envelope-from ) id 1rVKb2-00089t-0P; Thu, 01 Feb 2024 00:06:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674184.1048957; Thu, 01 Feb 2024 00:06: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 1rVKb1-00089m-TD; Thu, 01 Feb 2024 00:06:23 +0000 Received: by outflank-mailman (input) for mailman id 674184; Thu, 01 Feb 2024 00:06: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 1rVKb0-00089g-3y for xen-devel@lists.xen.org; Thu, 01 Feb 2024 00:06:22 +0000 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b8c1a7b3-c095-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 01:06: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: b8c1a7b3-c095-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1706745976; x=1707005176; bh=Zkfr6o6QSmCjTM/cjg8EpuSt+sqLtvN4C2pPrvDN4hM=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=dlaw3VA6LHfOfu5V1SBYAX0kzy7OrJVDZ4L8v3jViejRL/3VNMshrRFq8PM4aZhxf wdr93jWPS1/7w7dw1B/fN7Uuov0IleBNzlEWGdDV+x5xiHM08Im5xG8/YzPaDi8zcw 3n1c1pDg8Uxu8PZBFhuRokauO25Xr4lgce9c8puhtOnOEsM3zxYckL6BC93bYsQ5hu Ait3+og2WYiRj79+4rS2GNXk+y/851HBu5EIV05+Kcyh6wYAjl2Sg/37bONDKYdbTd p8/XW+CfVfp7100d96fZTA6EwTznIp9PWFAldGK/mtkxmB4U13UuZSKmMqTI9KD5TQ YoR1xtqefg5uQ== Date: Thu, 01 Feb 2024 00:05:58 +0000 To: xen-devel@lists.xen.org From: "John L. Poole" Subject: Nullifying Recently Introduced Xen Headers Check Message-ID: Feedback-ID: 80499891:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greetings, Gentoo Linux maintains two packages for Xen: =C2=A0 1) app-emulation/xen-tools ("xen-tools") =C2=A0 2) app-emulation/xen ("xen") xen-tools is a prerequisite to xen.=C2=A0 So a failure to install xen-tools will preclude any attempt to install xen. I acknowledge that building xen-tools before building xen is backwards and/or runs contrary to your project's way of building, but that is what the Gentoo paradigm has been. In trying to troubleshoot why a Gentoo 4.18.0 ebuild fails, I ended up downloading your archive and successfully building it. I then decided to compare the products built to see where they varied in processing order.=C2=A0 The Xen Project builds xen first, then the tools. To see a visualization of the to build systems and the object files they create matched in chronological order, see: https://salemdata.us/xen/gentoo-4.18.0/comparison_of_build_orders_Xen_4.18.= xhtml =C2=A0=C2=A0=C2=A0 or the LibreOffice workbook I created the comparison in= : https://salemdata.us/xen/gentoo-4.18.0/comparison_of_build_orders_Xen_4.18.= ods In March 2023, this commit added some sort of headers check: https://xenbits.xen.org/gitweb/?p=3Dqemu-xen.git;a=3Dcommit;f=3Dinclude/hw/= xen/xen_native.h;h=3De2abfe5ec67b69fb310fbeaacf7e68d61d16609e Specifically, the lines 4-6 in [qemu-xen.git] / include / hw / xen / xen_native.h: =C2=A0=C2=A0 4 #ifdef __XEN_INTERFACE_VERSION__ =C2=A0=C2=A0 5 #error In Xen native files, include xen_native.h before oth= er Xen headers =C2=A0=C2=A0 6 #endif cause Gentoo's build to error out.=C2=A0 See line 24790: =C2=A0=C2=A0 5 | #error In Xen native files, include xen_native.h before o= ther Xen headers at https://salemdata.us/xen/xen_tools_20240128_Sun_174740.script.html. What I have done is create a patch for a draft Gentoo ebuild which nullifie= s lines 4-6 by wrapping them in a comment: =C2=A0=C2=A0=C2=A0 --- a/tools/qemu-xen/include/hw/xen/xen_native.h =C2=A0=C2=A0=C2=A0 +++ b/tools/qemu-xen/include/hw/xen/xen_native.h =C2=A0=C2=A0=C2=A0 @@ -1,9 +1,9 @@ =C2=A0=C2=A0=C2=A0=C2=A0 #ifndef QEMU_HW_XEN_NATIVE_H =C2=A0=C2=A0=C2=A0=C2=A0 #define QEMU_HW_XEN_NATIVE_H =C2=A0=C2=A0=C2=A0 -#ifdef __XEN_INTERFACE_VERSION__ =C2=A0=C2=A0=C2=A0 +/* #ifdef __XEN_INTERFACE_VERSION__ =C2=A0=C2=A0=C2=A0=C2=A0 #error In Xen native files, include xen_native.h = before other Xen headers =C2=A0=C2=A0=C2=A0 -#endif =C2=A0=C2=A0=C2=A0 +#endif */ This patch allows the Gentoo xen-tools ebuild to successfully build. Question: is there a risk nullifying the above 3 lines in xen_native.h given Gentoo's backward build paradigm? Thank you. John Poole From xen-devel-bounces@lists.xenproject.org Thu Feb 01 00:15:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 00:15:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674190.1048967 (Exim 4.92) (envelope-from ) id 1rVKk9-0001Vy-1E; Thu, 01 Feb 2024 00:15:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674190.1048967; Thu, 01 Feb 2024 00:15: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 1rVKk8-0001Vr-Th; Thu, 01 Feb 2024 00:15:48 +0000 Received: by outflank-mailman (input) for mailman id 674190; Thu, 01 Feb 2024 00: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 1rVKk7-0001Vf-Qk for xen-devel@lists.xen.org; Thu, 01 Feb 2024 00:15:47 +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 0bbbb200-c097-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 01:15:46 +0100 (CET) Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-33ae3cc8a6aso231720f8f.2 for ; Wed, 31 Jan 2024 16:15:46 -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 m4-20020a5d6244000000b0033ae4a3b285sm12269746wrv.36.2024.01.31.16.15.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Jan 2024 16:15: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: 0bbbb200-c097-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706746546; x=1707351346; darn=lists.xen.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=wB6q9VBrbFIo6ekJmlUp4iZqdgxywdF1k8W9gXCxehw=; b=EPgaPeVNemS3jMOtjXCprzzwYgWF4vGtO+u1tI6CB2+UQBEIeJ6fRxwiy91thSJsQy Cgavz1WsRarSEGbN6MFldqfh4aV9R3ugrCNiR6iIsx70EGt44hbPZq9DJGz+Mb99wW32 hdQX8+PhJZ5IUqd9Fd6tHTj8i7a+F9ttZcfV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706746546; x=1707351346; 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=wB6q9VBrbFIo6ekJmlUp4iZqdgxywdF1k8W9gXCxehw=; b=edcxKaRSC0Zhor8X16zabhRJk2qg+QTHRI2uughIcByq1sjFmn0rk/a0DkLZzpPV18 jUdmqAbv+ZOrYWiZz6uErfLC3E6+1XNS6UF8TAV864EeCTkkHXOSEAL0XKMzRMJKim0D ULDk709Ncu91HxQszb6lFEQYbW6s93h1kDtj0IxKbwIjhyBVZxPShfzjfVhjfawkytId GPhmKqwR37ssqIgBXn9+thrYYqjy4PRDGbzIU4kd087iRf70CrhT0jvzxsdG+PZeDBFA PYyVsEqV9JONrobCIeQKbGS7ubW+DzSC87vi0jK4RvofXtj+t52R0uiBG+hbgtNBzuP6 i2FA== X-Gm-Message-State: AOJu0YxlFX6aBmHZA9zTSKIdp/a8zZtPdig+ALw+WNCpOlMLa/Agr1N5 ZeWcceCuaxRtLoJLWocL5M3gixe1jCfPKLQSd1L+0EwmKzGc3+GUgMT92+oFMQQ= X-Google-Smtp-Source: AGHT+IHZl+S8Way3RhddZvdYpiFGMASnHvje/NzNyk855TON3IX/JgvrZNVpAONtf6zrp4V4MaVF+w== X-Received: by 2002:a5d:4049:0:b0:33a:f51a:f7ba with SMTP id w9-20020a5d4049000000b0033af51af7bamr435736wrp.49.1706746546027; Wed, 31 Jan 2024 16:15:46 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUpLTGj+TmMpxpItyXt1HUMuJQgnCzdG5KlQS+4HIeEJGoApfGbq64860OqwH2HtdMGiFKSz2bLkxYpD3K3eCx+r9KdvZGtkB7TCl52l9F74DLxBd8Xbw8tN6Ov4w== Message-ID: Date: Thu, 1 Feb 2024 00:15:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Nullifying Recently Introduced Xen Headers Check Content-Language: en-GB To: "John L. Poole" , xen-devel@lists.xen.org, David Woodhouse 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/02/2024 12:05 am, John L. Poole wrote: > Greetings, > > Gentoo Linux maintains two packages for Xen: > >   1) app-emulation/xen-tools ("xen-tools") >   2) app-emulation/xen ("xen") > > xen-tools is a prerequisite to xen.  So a failure > to install xen-tools will preclude any attempt to install xen. > I acknowledge that building xen-tools before building xen > is backwards and/or runs contrary to your project's way of > building, but that is what the Gentoo paradigm has been. > > In trying to troubleshoot why a Gentoo 4.18.0 ebuild fails, > I ended up downloading your archive and successfully building it. > I then decided to compare the products built to see where > they varied in processing order.  The Xen Project builds xen first, > then the tools. > > To see a visualization of the to build systems and the object > files they create matched in chronological order, see: > > https://salemdata.us/xen/gentoo-4.18.0/comparison_of_build_orders_Xen_4.18.xhtml >     or the LibreOffice workbook I created the comparison in: > https://salemdata.us/xen/gentoo-4.18.0/comparison_of_build_orders_Xen_4.18.ods > > In March 2023, this commit added some sort of headers check: > > https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commit;f=include/hw/xen/xen_native.h;h=e2abfe5ec67b69fb310fbeaacf7e68d61d16609e > > Specifically, the lines 4-6 in [qemu-xen.git] / include / hw / xen / > xen_native.h: > >    4 #ifdef __XEN_INTERFACE_VERSION__ >    5 #error In Xen native files, include xen_native.h before other Xen > headers >    6 #endif > > cause Gentoo's build to error out.  See line 24790: > >    5 | #error In Xen native files, include xen_native.h before other > Xen headers > > at https://salemdata.us/xen/xen_tools_20240128_Sun_174740.script.html. > > What I have done is create a patch for a draft Gentoo ebuild which nullifies > lines 4-6 by wrapping them in a comment: > >     --- a/tools/qemu-xen/include/hw/xen/xen_native.h >     +++ b/tools/qemu-xen/include/hw/xen/xen_native.h >     @@ -1,9 +1,9 @@ >      #ifndef QEMU_HW_XEN_NATIVE_H >      #define QEMU_HW_XEN_NATIVE_H > >     -#ifdef __XEN_INTERFACE_VERSION__ >     +/* #ifdef __XEN_INTERFACE_VERSION__ >      #error In Xen native files, include xen_native.h before other Xen > headers >     -#endif >     +#endif */ > > This patch allows the Gentoo xen-tools ebuild to successfully build. > > Question: is there a risk nullifying the above 3 lines in xen_native.h > given Gentoo's backward build paradigm? CC'ing David who authored that Qemu patch.  He'll be best placed to answer. However, as a word of warning if you're not aware.  The name __XEN_INTERFACE_VERSION__ is massively dishonest; read it as if it said "unstable interfaces". We're working to stabilise the tools->xen interface, but the nice shiny future is still a while away. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Feb 01 00:23:50 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 00:23:50 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674195.1048976 (Exim 4.92) (envelope-from ) id 1rVKro-0003Ia-QD; Thu, 01 Feb 2024 00:23:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674195.1048976; Thu, 01 Feb 2024 00:23: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 1rVKro-0003IT-NO; Thu, 01 Feb 2024 00:23:44 +0000 Received: by outflank-mailman (input) for mailman id 674195; Thu, 01 Feb 2024 00:23: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 1rVKrn-0003IN-OO for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 00:23: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 26d7b74d-c098-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 01:23: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 D31196190F; Thu, 1 Feb 2024 00:23:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 646C0C433F1; Thu, 1 Feb 2024 00:23: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: 26d7b74d-c098-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706747020; bh=7gsKG6V5s1dopCQuysbsTz34HGC4+l+xc5j4okSwkgM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lk+5raA/Cc61dnv9T5cuz4gmbXaTbEiX742QUf0zqnvIfq3Fj3SYKTN/uoi3yP+g/ pLoelw6V1AJdY5MbbIOAYtjq2qesUk/3GIwLzdEFsN3PUAnwi+SxWwW3Lk9cgZsGoS qlbBbWMb45LrvVgTPSl5JJf+j443ewZ3jZ6m6+9GWMGFXHWIqsoJk6VP5mL+8net8k d2kwVXZdx5SbZTOwXM3ZVtzXTiOiHudjReNRanO2NxpAYRWNjdzws2AHMiA+mEOmcg c0zNjS8GO0+Zn4sPw2NrOEAj6LZ6IyjsmFrxzylSiyQWii7Fsps6xQ8mJ7fjWr3eN7 6nJN7zWOFch0g== Date: Wed, 31 Jan 2024 16:23:36 -0800 From: Jakub Kicinski To: Paul Durrant Cc: Jan Beulich , "netdev@vger.kernel.org" , Wei Liu , "xen-devel@lists.xenproject.org" Subject: Re: [PATCH net] xen-netback: properly sync TX responses Message-ID: <20240131162336.7d3ba09e@kernel.org> In-Reply-To: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> References: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 29 Jan 2024 14:03:08 +0100 Jan Beulich wrote: > Invoking the make_tx_response() / push_tx_responses() pair with no lock > held would be acceptable only if all such invocations happened from the > same context (NAPI instance or dealloc thread). Since this isn't the > case, and since the interface "spec" also doesn't demand that multicast > operations may only be performed with no in-flight transmits, > MCAST_{ADD,DEL} processing also needs to acquire the response lock > around the invocations. > > To prevent similar mistakes going forward, "downgrade" the present > functions to private helpers of just the two remaining ones using them > directly, with no forward declarations anymore. This involves renaming > what so far was make_tx_response(), for the new function of that name > to serve the new (wrapper) purpose. > > While there, > - constify the txp parameters, > - correct xenvif_idx_release()'s status parameter's type, > - rename {,_}make_tx_response()'s status parameters for consistency with > xenvif_idx_release()'s. Hi Paul, is this one on your TODO list to review or should we do our best? :) -- pw-bot: needs-ack From xen-devel-bounces@lists.xenproject.org Thu Feb 01 00:45:47 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 00:45:47 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674204.1048986 (Exim 4.92) (envelope-from ) id 1rVLD1-0006Yf-Kh; Thu, 01 Feb 2024 00:45:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674204.1048986; Thu, 01 Feb 2024 00: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 1rVLD1-0006YY-Hy; Thu, 01 Feb 2024 00:45:39 +0000 Received: by outflank-mailman (input) for mailman id 674204; Thu, 01 Feb 2024 00:45: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 1rVLCz-0006YN-TU for xen-devel@lists.xen.org; Thu, 01 Feb 2024 00:45:37 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 353b2bce-c09b-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 01:45:35 +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 4110jL33006593 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 31 Jan 2024 19:45:27 -0500 (EST) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.17.1/8.15.2/Submit) id 4110jLE7006592; Wed, 31 Jan 2024 16:45:21 -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: 353b2bce-c09b-11ee-8a43-1f161083a0e0 Date: Wed, 31 Jan 2024 16:45:21 -0800 From: Elliott Mitchell To: Jan Beulich Cc: Andrew Cooper , xen-devel@lists.xen.org Subject: Re: Thoughts on current Xen EDAC/MCE situation Message-ID: References: <111f5551-70fa-4ded-a62a-e0aa967b3c29@suse.com> 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 Wed, Jan 24, 2024 at 07:20:56AM -0800, Elliott Mitchell wrote: > On Wed, Jan 24, 2024 at 08:23:15AM +0100, Jan Beulich wrote: > > > > Third, as to Dom0's purposes of having the address: If all it is to use > > it for is to pass it back to Xen, paths in the respective drivers will > > necessarily be entirely different for the Xen vs the native cases. > > I'm less than certain of the best place for Xen to intercept MCE events. > For UE memory events, the simplest approach on Linux might be to wrap the > memory_failure() function. Yet for Linux/x86, > mce_register_decode_chain() also looks like a very good candidate. I did hope to get some response. It really does look like, aside from being x86-only, mce_register_decode_chain() is the ideal hook point. Xen could forward NMIs to Domain 0, then intercept them from the decode chain. For UEs Xen would mark the event handled, then create a new event for whichever domain (if any) was effected. Right now my main concern is several of the Linux MCE/EDAC drivers are growing `if (cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) return -ENODEV;` calls. This approach is being poisoned and will become quite difficult if this isn't stopped. The justification found for one instance was that it "removed one message", with no useful information. I cannot help suspecting it involved a hypervisor from Redmond, WA and their engineers are encouraged to poison interfaces used by others. -- (\___(\___(\______ --=> 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 Feb 01 03:32:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 03:32:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674208.1048998 (Exim 4.92) (envelope-from ) id 1rVNnm-0004IL-1s; Thu, 01 Feb 2024 03:31:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674208.1048998; Thu, 01 Feb 2024 03: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 1rVNnl-0004IE-Tn; Thu, 01 Feb 2024 03:31:45 +0000 Received: by outflank-mailman (input) for mailman id 674208; Thu, 01 Feb 2024 03:31:44 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVNnk-0004I4-AC; Thu, 01 Feb 2024 03:31: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 1rVNnk-0005dY-1a; Thu, 01 Feb 2024 03:31: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 1rVNnj-0005E8-Hz; Thu, 01 Feb 2024 03:31:43 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rVNnj-0005Ox-Go; Thu, 01 Feb 2024 03:31: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=jtC924xqWJRZxlyBAoCbZxTG0cODBUo0a61YtqXnzmk=; b=XvI+y/2Z9Rt++Gb4rlKrNigUCm WOZV02tm3sKwBM/ZdxjKr2wtSzS3q6WQoKqHAokzhTEpTN5daIzk6ArtlIUjG2326QnF80z6QY1C3 0SGXlzBSSt71W2dsOX1EWcW7Xa9BmUzVqOIPc1zlYaYgt1XrspjN2sWVpfT88P3LDMYc=; 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] 184535: tolerable FAIL - PUSHED X-Osstest-Failures: xen-unstable:test-amd64-i386-xl-qemut-debianhvm-i386-xsm:debian-hvm-install:fail:heisenbug xen-unstable:test-amd64-amd64-xl-rtds:guest-localmigrate/x10:fail:allowable 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-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-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-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-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-thunderx: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: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-libvirt: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-credit1:migrate-support-check:fail:nonblocking xen-unstable:test-armhf-armhf-xl-credit1: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-raw: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-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 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 X-Osstest-Versions-This: xen=cc6ba68edf6dcd18c3865e7d7c0f1ed822796426 X-Osstest-Versions-That: xen=4a7e71aa085170f1a13976507c8e248f8715f116 From: osstest service owner Date: Thu, 01 Feb 2024 03:31:43 +0000 flight 184535 xen-unstable real [real] flight 184546 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184535/ http://logs.test-lab.xenproject.org/osstest/logs/184546/ 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 184546-retest Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail REGR. vs. 184527 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184527 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184527 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184527 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184527 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 184527 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 184527 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184527 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184527 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184527 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184527 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 184527 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184527 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 15 migrate-support-check fail never pass test-amd64-i386-libvirt 15 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-thunderx 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 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-libvirt 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-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-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 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 version targeted for testing: xen cc6ba68edf6dcd18c3865e7d7c0f1ed822796426 baseline version: xen 4a7e71aa085170f1a13976507c8e248f8715f116 Last test of basis 184527 2024-01-30 06:02:22 Z 1 days Testing same since 184535 2024-01-31 00:07:55 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper 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 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 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 fail 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 4a7e71aa08..cc6ba68edf cc6ba68edf6dcd18c3865e7d7c0f1ed822796426 -> master From xen-devel-bounces@lists.xenproject.org Thu Feb 01 04:11:00 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 04:11:00 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674217.1049014 (Exim 4.92) (envelope-from ) id 1rVOPe-000113-4I; Thu, 01 Feb 2024 04:10:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674217.1049014; Thu, 01 Feb 2024 04:10: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 1rVOPe-00010w-1V; Thu, 01 Feb 2024 04:10:54 +0000 Received: by outflank-mailman (input) for mailman id 674217; Thu, 01 Feb 2024 04: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 1rVOPd-00010q-I6 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 04:10:53 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on062f.outbound.protection.outlook.com [2a01:111:f400:fe1f::62f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id e29dc848-c0b7-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 05:10:50 +0100 (CET) Received: from DU0PR04MB9417.eurprd04.prod.outlook.com (2603:10a6:10:358::11) by AM0PR04MB6836.eurprd04.prod.outlook.com (2603:10a6:208:187::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.26; Thu, 1 Feb 2024 04:10:47 +0000 Received: from DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::c499:8cef:9bb1:ced6]) by DU0PR04MB9417.eurprd04.prod.outlook.com ([fe80::c499:8cef:9bb1:ced6%3]) with mapi id 15.20.7249.023; Thu, 1 Feb 2024 04:10: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: e29dc848-c0b7-11ee-98f5-efadbce2ee36 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bxuci8oc2L6yTUp7UbN2BLK64Dw/5k1cBW5/hlcVrq0rMwbLBw3diikd+f8N2lTJOHHufMwtOoAcOZkNAxvxvWgNMF2l3mAFE1PvFYNg5Vgnbjv1Up6UCZRw2eQFMoAT4Io/pVgBcEkSa7gpW3/9bfOgTCUposgywM6RslX80CGKWU57VVzN1Ic4YDJ7yuRWNURepnmmF6qKBZKj11kfQrB0gCsleAC5D6rFoT3b6tf6KqOE6LqukgrbFUOT7D2KDI2KW+X7Wd0cRj+nbdt6JXW3pXYse9qf+mhxK2ihX61ow17qsnEqKcwye2WOM5t/JFrc+FhldDWH+enFNAJEfw== 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=DcVXz3h0TliXCAdcDKfzPkeUDq7pj0aXYjzX7MHA3hI=; b=Mal0n89NszSIHOutr+Qf+SJJjcwdsYH2H5yHqr5pemTMJrbeEzMnGvrrJE7SVy/VVYH3B9vXnCidOwAwEI/LBBiKG0rD7NKo6Xc5jECQ8p4C8CyKc/aRr7sdy9JChVmanNQB0rWwzKfb8POb6cyf54/V2rAcYzITVdYhd9odfGsGiSMz7mrcl4NEQaa1uzQiDyouvA4OfWMXr7U8QKDzMcy1tLhcPyH+fuiM4kSJ8moQdPREUZ4D3ptPOtWLfK3tP1YJ9KXIk2KDb4FM+/mRupvecoSauTFjFmhttZoCZOIIV2RbHceJ9R28fRznP1upGDnL+utse3vGdX+VXa+JXw== 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=DcVXz3h0TliXCAdcDKfzPkeUDq7pj0aXYjzX7MHA3hI=; b=CCjZnK1v9DKwnqdLy6gng359AVCmmqQBkb5TgUWTBl/YfemDXb0IlAvzxzORpR1B77humRALy+tuaRvO8bYHnzww6bUnWGZrf5fn/p7OUV6dtDbgNqYk3X9Zr1LoD42hnmzMRi2ONZZkU+BEL3klXY5uwU6GgXLNkJv11hEkh4A= From: Peng Fan To: John Ernberg , Julien Grall , 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/hE0ez5bDz198AgAA1LICAANMm8A== Date: Thu, 1 Feb 2024 04:10:46 +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> In-Reply-To: <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> 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_|AM0PR04MB6836:EE_ x-ms-office365-filtering-correlation-id: 335956e2-f29d-4a32-8aa1-08dc22dbc475 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sqH9RcPapi5UzcfyjoCF0sDBJaS5dHPs9J9oW0RMSLIHLCq8tLW0mMzytOKOhwQ6c3z04RL6gmJM8nV9kaQ2YSCl3XLFQRZ0WtEVsKnz7BZepBp2bk23QB0D1ah6SrzcVrosRZJAjYqPjbJs9fZNbYfI2j9izaysCjhMswVXJoXtpx0JJzzesHrwdZMHvkp8WJYV2Bw0G1112EP7fq81ALiaEIcCLiYl0uY0zpzAzvGMC+eZK+bcr1AegWgUn3T7SL7sb47jCBqAT2ScqsU+TaPvwkQC9yR7FYwQeQyg2lo2ZKXhZtfJPAc1bKYDf/6qg4+cIZ1UsIbq3RMGTl+X0I2dPT7IzaFueftjxF3cHN7vIkxE0SNwN+MxDv53g2uobrK1l6UwOsvFTHtFWqdQJZmrJR3aAFt3SAo2EW0ApGUepW0O2+1s+bRU+qAEmlGzSSOuVl3D3vF9aDfgOFhNk2CyOVRS1SM61zf77plrm9RuUFAQBfsc51smK3YJFs5WFdo6sDodS4umToOKmDKfOeDbVJzJCgzeVSgG1SQmwza+l1XQG8Kz2otHxrQ6WvrzDN8iHowKgLsRE4uBjdGMlhZDCiN4Fl3bzIbgXg7l4WzDEhCGGpYLWtTIPzH6akiXT7b2wngzWODWCqeOzVWirQ== 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)(376002)(366004)(346002)(136003)(396003)(39860400002)(230922051799003)(1800799012)(64100799003)(451199024)(186009)(71200400001)(6506007)(7696005)(53546011)(9686003)(8676002)(26005)(8936002)(4326008)(52536014)(44832011)(2906002)(64756008)(316002)(5660300002)(33656002)(54906003)(66556008)(66476007)(66446008)(86362001)(110136005)(38070700009)(66946007)(76116006)(41300700001)(966005)(45080400002)(478600001)(122000001)(55016003)(83380400001)(38100700002)(32563001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?uz/duHf/AIjb52JGboPfCHdKUYcch1AZdVYbf196hs0qUguAfQou5cCLeT?= =?iso-8859-1?Q?baHIYTBy6tzDFj5mfyKyWPBDyT20O7XVeKsU/6n4+ZonOjoAXL7orvkkiT?= =?iso-8859-1?Q?+N3kpFu1A5rpVIcwB7Ry8+MfF16PIGb9oRpgB3pzrPyjzizAYd+fAqu0Kt?= =?iso-8859-1?Q?w4/VyNH29liEz62gjlk5tg3ZnQTTmIUGO22+UEMlgQzJqxwuFDlqpramEu?= =?iso-8859-1?Q?eKf5LVpJnyoMnGkAvGvK3rtxzLs76dDGHcOYU4QIl2WZUb/+kTl+YepJ0c?= =?iso-8859-1?Q?ZOCihAtfoqS1bWTPoEQE3hTXpBII08YUBQfWCykZilP5B3MXo8NfFAFkjH?= =?iso-8859-1?Q?CR3LCZDlJp17+tRsQjxW5mJuyBeSAD3E4VrMgRcuYrrXrzY9tae0PDIHVo?= =?iso-8859-1?Q?Zhws0duLG2X2gdLQ1JUyTfN50Tii5HBWYt29flJOlBWinhg4eV7t3616pY?= =?iso-8859-1?Q?QgvxL8ZXMhn3k78m7oYQyJXF7bI0s4P50Voemt70evd7Q21+gt7SOg/ktb?= =?iso-8859-1?Q?Dth/gh75J+pNN7mJ29VKYBxOpFgzHafWq6JB3kImvLQ5wufW1DZUk6/TFP?= =?iso-8859-1?Q?w6FqN4gAePUG8hKx5j7orOuJceHrkSqfHatDn/AIcIQDmDPEKcMdk3uIjW?= =?iso-8859-1?Q?6QsL5axxgY5spi+XrRfkE/RCNt8e4xgPyGjaFYluUHT0JVFVn2QGDsvOkP?= =?iso-8859-1?Q?PBtAlick8egCt4i2y8DykBHz84tbZxLudfWP8PB8BSEI+Edpx3YNUzFhIp?= =?iso-8859-1?Q?xg/fZMuOxY7kcdaJUV3+GmiMZuFD+PSXE715tAtMOvbIF484qPzaudNpLf?= =?iso-8859-1?Q?Fs6oOz7F8ghx/CMnjtJVH9bcWVRWdkQmgJg9UqP/q2oI4bJdV7/f2IqSHN?= =?iso-8859-1?Q?QedsVGMVpFeRto54c6DCkJhWOe5mHe8CZZ5T8Mv7hxMZhf2gMjPyyEFRS5?= =?iso-8859-1?Q?nPFCPrchbTGkJx7rWHPLNczAU1mKPBDM8fC8YiW4J03RYxu9Gega5tKq09?= =?iso-8859-1?Q?mCL/zlawo9L6JkcRVwMxzUUZOeZ26cXbHuI9j+NgdiAcO+V4r359GuN0qq?= =?iso-8859-1?Q?z8CJPrZyoXR214Mgir81YUEL8oJexk2w3Ov3pLCNRztmZ+3DPvfclN56pQ?= =?iso-8859-1?Q?Rl24ZMQy6hQDZ7rdX/+fMPgvsDVj3YAT1m2/cPkeC0CBeqX0moXoHWfGF8?= =?iso-8859-1?Q?Bih6P1rdPcp00/Dm0Dwoo5YDjtV8ajumt/RwBRQRJLquKM6aiBRE5OziAe?= =?iso-8859-1?Q?8k8Mgpn0uqln47EJtfCmZeaPnx/H6pXzyV4cpNtKeCXwnlnJepC8M2zbW5?= =?iso-8859-1?Q?3+KE+KsI+JWeiUFbzNd9uTZpcK210dtDGsktFaO/mRlIkAt1S9e7ozByE0?= =?iso-8859-1?Q?lX/Sb37N2UAV+h1+YAD/yb8CKz9mOCJp9kifa0MV6KrLke+VJNNEpkXseH?= =?iso-8859-1?Q?pJB1NE8UxW3A7HC0E0bGPvG/MqBA5tmsJG4OIRtPTe8WwzMW0RZAS/sEsg?= =?iso-8859-1?Q?u7npJevjaVAfLxd/8dXHf0bOwXJYSF9Hf4bvC2IGuI99OjXyjeofV2gvc+?= =?iso-8859-1?Q?Uc+PSvJW/sQxR07kKD0tHvWSOkCYTpp3N5k0IFx7RrEaZ/ZrxlXgeoLdK9?= =?iso-8859-1?Q?pWQRyhHPd/4EY=3D?= Content-Type: text/plain; charset="iso-8859-1" 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: 335956e2-f29d-4a32-8aa1-08dc22dbc475 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2024 04:10:46.8616 (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: Xwvpi/unVz/Zhwr+n4EvBlXIWxxgOfxTqfYpYQzoC/fimMrUkzd3XudHskmIRRmobFhrB+k/acpyiE6381Bvtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB6836 > Cc: Jonas Blixt ; xen-devel@lists.xenproject.org > Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue >=20 > Hi Julien, >=20 > On 1/31/24 13:22, Julien Grall wrote: > > Hi, > > > > On 31/01/2024 11:50, John Ernberg wrote: > >> When using Linux for dom0 there are a bunch of drivers that need to > >> do SMC SIP calls into the PSCI provider to enable certain hardware > >> bits like the watchdog. > > > > Do you know which protocol this is under the hood. Is this SCMI? >=20 > I think I confused myself here when I wrote the commit log. >=20 > The EL3 code in our case is ATF, and it does not appear to be SCMI, nor P= SCI. > The register usage of these SMC SIP calls are as follows: > a0 - service > a1 - function > a2-a7 - args >=20 > In ATF the handler is declared as a runtime service. >=20 > Would the appropriate commmit message here be something along the lines > of below? > """ > 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 watc= hdog. > """ > > > >> > >> Provide a basic platform glue that implements the needed SMC forwardin= g. > >> > >> Signed-off-by: John Ernberg > >> --- > >> NOTE: This is based on code found in NXP Xen tree located here: > >> https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgi= t > >> hub.com%2Fnxp-imx%2Fimx-xen%2Fblob%2Flf- > 5.10.y_4.13%2Fxen%2Farch%2Far > >> > m%2Fplatforms%2Fimx8qm.c&data=3D05%7C02%7Cpeng.fan%40nxp.com%7C > 573b599a > >> > 4b4143ceca1d08dc2271e5be%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C > 0%7C0%7 > >> > C638423119777601548%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > wMDAiLCJQI > >> > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3DZO > 0TXjL6 > >> g0W7TIZo8x8lTNBXEZW%2BDNcLPndWlEf5D2A%3D&reserved=3D0 > > > > Anything after --- will be removed while applied to the three. I think > > this NOTE should be written down in the commit message. >=20 > Ack. > > > > You also possibly want a signed-off-by from Peng as this is his code. >=20 > @Peng: May I add a sign-off from you? Yeah. You could add my sign off. > > > >> > >> =A0 xen/arch/arm/platforms/Makefile |=A0 1 + > >> =A0 xen/arch/arm/platforms/imx8qm.c | 65 > >> +++++++++++++++++++++++++++++++++ > >> =A0 2 files changed, 66 insertions(+) > >> =A0 create mode 100644 xen/arch/arm/platforms/imx8qm.c > >> > >> diff --git a/xen/arch/arm/platforms/Makefile > >> b/xen/arch/arm/platforms/Makefile index 8632f4115f..bec6e55d1f > 100644 > >> --- a/xen/arch/arm/platforms/Makefile > >> +++ b/xen/arch/arm/platforms/Makefile > >> @@ -9,5 +9,6 @@ obj-$(CONFIG_ALL_PLAT)=A0=A0 +=3D sunxi.o > >> =A0 obj-$(CONFIG_ALL64_PLAT) +=3D thunderx.o > >> =A0 obj-$(CONFIG_ALL64_PLAT) +=3D xgene-storm.o > >> =A0 obj-$(CONFIG_ALL64_PLAT) +=3D brcm-raspberry-pi.o > >> +obj-$(CONFIG_ALL64_PLAT) +=3D imx8qm.o > >> =A0 obj-$(CONFIG_MPSOC_PLATFORM)=A0 +=3D xilinx-zynqmp.o > >> =A0 obj-$(CONFIG_MPSOC_PLATFORM)=A0 +=3D xilinx-zynqmp-eemi.o diff --g= it > >> a/xen/arch/arm/platforms/imx8qm.c > b/xen/arch/arm/platforms/imx8qm.c > >> new file mode 100644 index 0000000000..a9cd9c3615 > >> --- /dev/null > >> +++ b/xen/arch/arm/platforms/imx8qm.c > >> @@ -0,0 +1,65 @@ > >> +/* 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 > >> + > >> +static const char * const imx8qm_dt_compat[] __initconst =3D { > >> +=A0=A0=A0 "fsl,imx8qm", > >> +=A0=A0=A0 "fsl,imx8qxp", > >> +=A0=A0=A0 NULL > >> +}; > >> + > >> +static bool imx8qm_smc(struct cpu_user_regs *regs) { > > > > Your implementation below will not only forward SMC for dom0 but also > > for any non-trusted domains. Have you investigated that all the SIP > > calls are safe to be called by anyone? >=20 > We use pure virtualized domUs, so we do not expect any calls to this SMC > interface from the guest. I'll limit it to dom0. Would you mind to share what features are supported in your DomU? Pure virtualized, you using xen pv or virtio? Thanks, Peng. > > > > But even if we restrict to dom0, have you checked that none of the > > SMCs use buffers? > I haven't found any such instances in the Linux kernel where a buffer is = used. > Adding a call filtering like suggested below additions of such functions = can be > discovered and adapted for if they would show up later. > > > > Rather than providing a blanket forward, to me it sounds more like you > > want to provide an allowlist of the SMCs. This is more futureproof and > > avoid the risk to expose unsafe SMCs to any domain. > > > > For an example, you can have a look at the EEMI mediator for Xilinx. >=20 > Ack. Do you prefer to see only on SMCCC service level or also on function > level? (a1 register, per description earlier) > > > > Cheers, > > >=20 > Thanks! // John Ernberg From xen-devel-bounces@lists.xenproject.org Thu Feb 01 04:51:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 04:51:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674221.1049024 (Exim 4.92) (envelope-from ) id 1rVP2Y-0006Zp-3r; Thu, 01 Feb 2024 04:51:06 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674221.1049024; Thu, 01 Feb 2024 04:51: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 1rVP2Y-0006Zi-1D; Thu, 01 Feb 2024 04:51:06 +0000 Received: by outflank-mailman (input) for mailman id 674221; Thu, 01 Feb 2024 04:51: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 1rVP2X-0006Zb-71 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 04:51:05 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on20627.outbound.protection.outlook.com [2a01:111:f400:7eaa::627]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 7eb4801b-c0bd-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 05:51:01 +0100 (CET) Received: from PH8PR02CA0020.namprd02.prod.outlook.com (2603:10b6:510:2d0::9) by BY5PR12MB4243.namprd12.prod.outlook.com (2603:10b6:a03:20f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.8; Thu, 1 Feb 2024 04:50:57 +0000 Received: from SN1PEPF0002BA4C.namprd03.prod.outlook.com (2603:10b6:510:2d0:cafe::22) by PH8PR02CA0020.outlook.office365.com (2603:10b6:510:2d0::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.26 via Frontend Transport; Thu, 1 Feb 2024 04:50:57 +0000 Received: from SATLEXMB03.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.7249.19 via Frontend Transport; Thu, 1 Feb 2024 04:50:57 +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.34; Wed, 31 Jan 2024 22:50:56 -0600 Received: from [172.23.114.18] (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server id 15.1.2507.34 via Frontend Transport; Wed, 31 Jan 2024 22: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: 7eb4801b-c0bd-11ee-98f5-efadbce2ee36 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DIbXHSsvKKbwgnWF8/gmW5lIfPKu8vhpGid9qZlFs+a88X/IieMq8OiwFhHlnelS+PgEnWYum3Qcoa3SzktP2B6GCBxPkhOuRCBo8pfa/GZV9ti+wLQgUSlu0dgtcbw26WTqju04eDz5AB2ePU5bO/8+ubXm86fRGdWiZsqiR9Cj3Eo8LR9klGYQxQIS6zyQoLjUAliQ8JnnGHo7AVUz8kZ8jfGAwwZSAniCXSHmust6uZMWeK1opqFlwB1aAEnN3luD5+C8e80j5ogamundBAnTO+rOI17JN+oZ3pRHRyhtaT501Bb34Rn1YCIiXIRQTvrBAOXlU2EhWorjyVh5wQ== 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=Ii7bxJk70kAfTZiQJJ3NC2wsY5BfdVr76TAoUdYYDxA=; b=QLXRfH3Z/3ZU3Yf9dflSYEd0n5H9XvU/iYzv+YFchIuFcP593y7ExfzxObUSlbiwUsUONEVSXzMMo/md/Ke2VWEEO4UDBCoLkL9DkiTCERB9jk3ewgQnQjIp/OtDBJesT0JO5ZRNYgcn37rfgCL0cwS5N57g8PSCHFcJGCkYsvgW2GN2NHcoCV51ZS6FOHBEv0DsdhjZU555ONqSZ0FGXHcREplpgJDDxbbsdbI/XCrxRiv1ZZOY5sIjkvQ27bB6SByM7Cwevy2UWalMBNkV6v8xnIauTobmL3/kKq+ZeDnMCslXROLXQfDqhsUTuTzlVoGlQSNCxqPnmgdgcP8HDg== 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=Ii7bxJk70kAfTZiQJJ3NC2wsY5BfdVr76TAoUdYYDxA=; b=Cj77J2EvHz6DKCZrxppEGXAAK5IHPmptx+4FozOmzTuXWFlc4yuHQcSU904FW2DIckaBVA3Aj8O/6NCsInU+vf6WEFL65SR+RUBTJ04ai1nw9zj+w6GhZUV8UUAHd1v2WwpDuC1GQcQcDppv7u2b1/qnkMiuWRvIpbnlhKbGgbM= 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: <48a16cb3-9cb9-4b7d-a950-f190a9a64bc2@amd.com> Date: Wed, 31 Jan 2024 23:50:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 10/15] vpci/header: emulate PCI_COMMAND register for guests Content-Language: en-US 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: <20240109215145.430207-1-stewart.hildebrand@amd.com> <20240109215145.430207-11-stewart.hildebrand@amd.com> <50e79338-b2fd-40e9-b754-4e725e27ceb3@suse.com> From: Stewart Hildebrand In-Reply-To: <50e79338-b2fd-40e9-b754-4e725e27ceb3@suse.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PEPF0002BA4C:EE_|BY5PR12MB4243:EE_ X-MS-Office365-Filtering-Correlation-Id: e1056df2-3584-4de1-804f-08dc22e16149 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: noopwhAvahLcVlVQN7DyVrhMIWwmcUpbQaEAIZTFLsR4mCgOa/zdZXvq8JcfjW60+rf0wyaQhLqATH6pANyCkMTpYQHVUP69Wsq3ZTiO3+yFbIS6J4Qx2wM1Nka2bfJ7Y/Y0r4Zdv1OdH72zvmzn1T3sYR+mBhoebpIzPT1P44Iyd3lpdpw33p5LUzT6BHn+ecwYaoWKRA7sUmBxvVlC/mRhiCXUjCtS0KSOelhCWiXjC/rvWrICH8/Qqmd3fPYqmtYdWg9RhwJwgwA4m07xjcYii+of6Cvgcfnf/aZ0MHOY74prxNrslcelJHjzHBB2juQZL/i4eRvuQCJsCM0J4RMDd2Nt/bWaj1slWK0icJf0NptURICBSXxPwU34NEW2Z2S6vh0GGBoWbVBvrGDSopSlqr112uyS2SMdmLPBKygWq8fkrCCiFTCnqDM1NrOySqsgyPSq3R0nLs5Sh47UqQAUwZs8Kibm8uK5U2sI7EPFSwNnIPqpgxf/qDTzbPD2yjHAil2QtzEKJPn+1XgfLleepQs5p9UvHg1rlt8IMZto95W11bXouvHqWgAWy/AkfoZ6IHWfWOlBJeXVCtUmufns8/30MeFruxxcBaGM5naYZUA10PxWX2CXiQ51tZ0oWS/rrvTOB46BpLBQcXPr9I7yRKrz5zfSfT9pUv2/JbZcCoiTU3+bKkpwU0CyJwDIMZ/eQif75FdF7c+3ybU7bxM+kEoHamooBtS9mgxJbah4/ftDnm/1ZqoBHFSl7+Fsg25U296dlaiOQ0zTByeEPdOvNObwzOwzT+3ZV3/kdVUOruwkbDP2S+Cc2nnCUI6aWdW51mywp9iRzztWcwKtog== 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)(4636009)(39860400002)(136003)(346002)(376002)(396003)(230922051799003)(186009)(82310400011)(451199024)(64100799003)(1800799012)(46966006)(40470700004)(36840700001)(41300700001)(47076005)(36860700001)(8936002)(44832011)(4326008)(2906002)(8676002)(5660300002)(70206006)(7416002)(31696002)(86362001)(70586007)(36756003)(54906003)(16576012)(81166007)(83380400001)(82740400003)(356005)(6916009)(316002)(53546011)(478600001)(966005)(2616005)(336012)(426003)(40480700001)(40460700003)(26005)(31686004)(43740500002)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2024 04:50:57.4335 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e1056df2-3584-4de1-804f-08dc22e16149 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: SN1PEPF0002BA4C.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4243 On 1/25/24 10:43, Jan Beulich wrote: > On 09.01.2024 22:51, Stewart Hildebrand wrote: >> --- a/xen/drivers/vpci/header.c >> +++ b/xen/drivers/vpci/header.c >> @@ -168,6 +168,9 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd, >> if ( !rom_only ) >> { >> pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd); >> + /* Show DomU that we updated P2M */ >> + header->guest_cmd &= ~PCI_COMMAND_MEMORY; >> + header->guest_cmd |= cmd & PCI_COMMAND_MEMORY; >> header->bars_mapped = map; >> } > > I don't follow what the comment means to say. The bit in question has no > real connection to the P2M, and the guest also may have no notion of the > underlying hypervisor's internals. Likely connected to ... Indeed. If the comment survives to v13, I'll update it to: /* Now that we updated P2M, show DomU change to PCI_COMMAND_MEMORY */ > >> @@ -524,9 +527,26 @@ static void cf_check cmd_write( >> { >> struct vpci_header *header = data; >> >> + if ( !is_hardware_domain(pdev->domain) ) >> + { >> + const struct vpci *vpci = pdev->vpci; >> + >> + if ( (vpci->msi && vpci->msi->enabled) || >> + (vpci->msix && vpci->msix->enabled) ) >> + cmd |= PCI_COMMAND_INTX_DISABLE; >> + >> + /* >> + * Do not show change to PCI_COMMAND_MEMORY bit until we finish >> + * modifying P2M mappings. >> + */ >> + header->guest_cmd = (cmd & ~PCI_COMMAND_MEMORY) | >> + (header->guest_cmd & PCI_COMMAND_MEMORY); >> + } > > ... the comment here, but then shouldn't it be that the guest can't even > issue a 2nd cfg space access until the present write has been carried out? > Otherwise I'd be inclined to claim that such a partial update is unlikely > to be spec-conformant. Due to the raise_softirq() call added in 3e568fa9e19c ("vpci: fix deferral of long operations") my current understanding is: when the guest toggles memory decoding, the guest vcpu doesn't resume execution until vpci_process_pending() and modify_decoding() have finished. So I think the guest should see a consistent state of the register, unless it was trying to read from a different vcpu than the one doing the writing. Regardless, if the guest did have an opportunity to successfully read the partially updated state of the register, I'm not really spotting what part of the spec that would be a violation of. PCIe 6.1 has this description regarding the bit: "When this bit is Set" and "When this bit is Clear" the device will decode (or not) memory accesses. The spec doesn't seem to distinguish whether the host or the device itself is the one to set/clear the bit. One might even try to argue the opposite: allowing the bit to be toggled before the device reflects the change would be a violation of spec. Since the spec is ambiguous in this regard, I don't think either argument is particularly strong. Chesterton's fence: the logic for deferring the update of PCI_COMMAND_MEMORY in guest_cmd was added between v10 and v11 of this series. I went back to look at the review comments on v10 [1], but the rationale is still not entirely clear to me. At the end of the day, with the information I have at hand, I suspect it would be fine either way (whether updating guest_cmd is deferred or not). If no other info comes to light, I'm leaning toward not deferring because it would be simpler to update the bit right away in cmd_write(). [1] https://lore.kernel.org/xen-devel/ZVy73iJ3E8nJHvgf@macbook.local/ > >> @@ -843,6 +885,15 @@ static int cf_check init_header(struct pci_dev *pdev) >> if ( cmd & PCI_COMMAND_MEMORY ) >> pci_conf_write16(pdev->sbdf, PCI_COMMAND, 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. >> + */ >> + if ( !is_hwdom ) >> + cmd &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO); >> + header->guest_cmd = cmd; > > With PCI_COMMAND_MEMORY clear, the hw reg won't further be written on the > success return path. Yet wouldn't we better clear PCI_COMMAND_IO also in > hardware (until we properly support it)? Yes, I'll clear PCI_COMMAND_IO in hardware too > > I also think the insertion point for the new code isn't well chosen: The > comment just out of context indicates that the code in context above is > connected to the subsequent code. Whereas the addition is not. I'll rearrange it > >> --- a/xen/drivers/vpci/msi.c >> +++ b/xen/drivers/vpci/msi.c >> @@ -70,6 +70,15 @@ 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. >> + */ > > Nit: This ought to be a single line comment, just like ... OK, I'll make it a single line > >> + if ( !is_hardware_domain(pdev->domain) ) >> + { >> + pci_intx(pdev, false); >> + pdev->vpci->header.guest_cmd |= PCI_COMMAND_INTX_DISABLE; >> + } >> } >> else >> vpci_msi_arch_disable(msi, pdev); >> --- 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; >> + } > > ... the similar code here has it. > > In both cases, is it really appropriate to set the bit in guest view? I added this based on Roger's comment at [2]. Roger, what do you think? I don't believe QEMU updates the guest view in this manner. [2] https://lore.kernel.org/xen-devel/ZLqI65gmNj1XDBm4@MacBook-Air-de-Roger.local/ From xen-devel-bounces@lists.xenproject.org Thu Feb 01 06:57:10 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 06:57:10 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674225.1049035 (Exim 4.92) (envelope-from ) id 1rVR0L-0005dj-Un; Thu, 01 Feb 2024 06:56:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674225.1049035; Thu, 01 Feb 2024 06:56: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 1rVR0L-0005dc-QZ; Thu, 01 Feb 2024 06:56:57 +0000 Received: by outflank-mailman (input) for mailman id 674225; Thu, 01 Feb 2024 06:56:56 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVR0K-0005dQ-Gl; Thu, 01 Feb 2024 06:56: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 1rVR0K-0001UG-9k; Thu, 01 Feb 2024 06:56: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 1rVR0J-0005j4-QC; Thu, 01 Feb 2024 06:56:55 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rVR0J-0004C4-Pb; Thu, 01 Feb 2024 06:56: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=fzfFMqCmBHa+JxmDb2qyVL+C8MkfC3MyFUph87Y9fZY=; b=NauGs1tnS908U0SbmvA4SADTC/ id/Wu2vVLUaGANUqO47C76Gf818BPr0/wsXkBR1+UbL+HPJtzSH72ycqIF8RMUURqxU6GPpyI8khZ FkQyjeNUqFplv4rOVGI8QPj5FqBATOabmSK9Xf4CqZiCX1OlumUty2VXHEpjURllqPi8=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 184537: tolerable all pass - PUSHED X-Osstest-Failures: libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:saverestore-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-raw:migrate-support-check:fail:nonblocking libvirt:test-arm64-arm64-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=2757e91c2b28b704d9a0b586fb60012450110b1a X-Osstest-Versions-That: libvirt=3a3f73ea9f1925ca5e256fa54c5aa451ddeaa19e From: osstest service owner Date: Thu, 01 Feb 2024 06:56:55 +0000 flight 184537 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/184537/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184526 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184526 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184526 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-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt 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-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-libvirt 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-libvirt 15 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-qcow2 15 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 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-raw 14 migrate-support-check fail never pass test-arm64-arm64-libvirt-raw 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: libvirt 2757e91c2b28b704d9a0b586fb60012450110b1a baseline version: libvirt 3a3f73ea9f1925ca5e256fa54c5aa451ddeaa19e Last test of basis 184526 2024-01-30 04:18:50 Z 2 days Testing same since 184537 2024-01-31 04:24:45 Z 1 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Göran Uddeborg Michal Privoznik Pavel Hrdina Purna Pavan Chandra Aekkaladevi 김인수 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt pass test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 pass test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw pass test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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/libvirt.git 3a3f73ea9f..2757e91c2b 2757e91c2b28b704d9a0b586fb60012450110b1a -> xen-tested-master From xen-devel-bounces@lists.xenproject.org Thu Feb 01 07:39:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 07:39:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674232.1049044 (Exim 4.92) (envelope-from ) id 1rVRfd-0002hy-55; Thu, 01 Feb 2024 07:39:37 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674232.1049044; Thu, 01 Feb 2024 07:39: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 1rVRfd-0002hr-2P; Thu, 01 Feb 2024 07:39:37 +0000 Received: by outflank-mailman (input) for mailman id 674232; Thu, 01 Feb 2024 07:39: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 1rVRfb-0002hl-Uy for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 07:39:35 +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 0a8e9613-c0d5-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 08:39:33 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40e72a567eeso5785675e9.0 for ; Wed, 31 Jan 2024 23:39: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 10-20020a05600c22ca00b0040ef8aa4822sm3522786wmg.38.2024.01.31.23.39.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Jan 2024 23:39: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: 0a8e9613-c0d5-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706773173; x=1707377973; 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=bz5FmuhEJiQexu5mu42jZymD7KqSCxtSIt0Um8+gwT4=; b=db6x70WhrqzoW5Ng8Iau5RWM6t9mXmB3xi9kcOmNmjIrGb1Cen8gjHHvzgBcp/TF0H P4BS//6BeqqCIHw0tXj55TwHne5wwPup2CthRnmWGVzRBgCGNTKUrdVqFG9viKL8wFNY YFGRmo0/OwvdQ34q+QX11+w+MU06hXpvQDxz6IK15iJJSQTgYgcL5PsDqYfuls2fQLuW G1AaA920xaPrfQ7w01CHgISagsP71FmkZSsuGCVC4GDiFe/zjiG54eOAzuhw7nGga9y5 jX8oRgQpWJW6k5lR6STCOij7OUD2bRBMn0uOxHksJtIHEC83P3HDaE+7dXZE+nVvkEqn eWXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706773173; x=1707377973; 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=bz5FmuhEJiQexu5mu42jZymD7KqSCxtSIt0Um8+gwT4=; b=nI5azqFofOsk0vhKLeGGb7ABiRHKji4RqThAGwPNLFikjLag0M0SCOgYbuQsnoWStN bZ2zB4Q65uZZsExPWYZo3EuRPwADZ40gE2ws4qLapaqzMYUDRiCezYsuItAfF3gtrLba IX1VKbI88q1DWrZ1qNjS85JXUWGz2BGPBzNya0e64bi5GWDJNqG6Mns1vnmJypQtE+vb RcKSD6y6/vIYotyvWYYIkVVLmd+0jGgalAVmWOM08GA9XbLYjsPuvC/FxiFqnDSOW5ko eHQoqA6T8dYd86Ptmr8PBG0R6vpDKoJ+X5xHAmBNto1mYa60EtIBkJKo2mOMj2PQFost +mLQ== X-Gm-Message-State: AOJu0Yw9JQpl72P5F4aM7aaok3H1ymzt4hmmgVK556tT4e9FgWG2hW04 t8mswSdSeF2q52E5kQYAoiesDje4AayPc8iJbXNOWd3kTj+w+M/Idi9P21oujXB5LV7LnUlBm0I = X-Google-Smtp-Source: AGHT+IHI+PDZQn2TwuOAWsQO5Xun50aTkX0BHz5ysmzYQWPCRPzhA7d12I0X6nQ4pfD8oCB7K9+R8w== X-Received: by 2002:a05:600c:538d:b0:40e:66ba:7fff with SMTP id hg13-20020a05600c538d00b0040e66ba7fffmr3798549wmb.19.1706773172939; Wed, 31 Jan 2024 23:39:32 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVkJeNTuUFK4VV99ciwxWA8mAtOgklaMsawAgkLQgEbncOZYC7E1zsj0RukpKDSFqGb6ZYlQbFlvq73DZwyvKFeZyqX+aFzsnhD6IGVEYKttQ== Message-ID: <062053aa-455e-43d6-bc11-e25dc8052878@suse.com> Date: Thu, 1 Feb 2024 08:39:31 +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] shim: avoid building of vendor IOMMU code Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+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 for IOMMU code in the shim. Disable at least the vendor- specific code, until eventually IOMMU code can be disabled altogether. Signed-off-by: Jan Beulich --- a/xen/arch/x86/configs/pvshim_defconfig +++ b/xen/arch/x86/configs/pvshim_defconfig @@ -21,5 +21,7 @@ CONFIG_EXPERT=y # CONFIG_LIVEPATCH is not set # CONFIG_SUPPRESS_DUPLICATE_SYMBOL_WARNINGS is not set # CONFIG_TRACEBUFFER is not set +# CONFIG_AMD_IOMMU is not set +# CONFIG_INTEL_IOMMU is not set # CONFIG_DEBUG is not set # CONFIG_GDBSX is not set From xen-devel-bounces@lists.xenproject.org Thu Feb 01 08:15:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 08:15:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674240.1049055 (Exim 4.92) (envelope-from ) id 1rVSDv-0008P1-3R; Thu, 01 Feb 2024 08:15:03 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674240.1049055; Thu, 01 Feb 2024 08:15: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 1rVSDv-0008Ou-0O; Thu, 01 Feb 2024 08:15:03 +0000 Received: by outflank-mailman (input) for mailman id 674240; Thu, 01 Feb 2024 08:15: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 1rVSDt-0008Oo-EI for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 08:15:01 +0000 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [2a00:1450:4864:20::32f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id fa7cb8c8-c0d9-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 09:14:54 +0100 (CET) Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40ef64d8955so5840325e9.3 for ; Thu, 01 Feb 2024 00:14: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 bj26-20020a0560001e1a00b0033ae6530969sm12754030wrb.85.2024.02.01.00.14.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 00:14: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: fa7cb8c8-c0d9-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706775294; x=1707380094; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=uXX6851uCjtiZLhZz0jMQytjWVPIVDPo0oUudLzGlF4=; b=HGFbnaYFM2/SoDxApgOSazElODc2mdLTO6gu/W8FGrRvkrF9UqywRI3rqxHNkpb7e7 bpa+u8o/ct+nTOdMXi5Huyn8Ix1Dax+9pWGIcnKL5tZtXN7qSRDBLLvGeltFsWemGgIw C9yaTSeuLihcBZW+XsNxVdMcBEe34o9pVd93Yt5ieJfRQqiygaplHk6wZSDdKzsWJxgR 9i2l8aoPz4IeQyBsCnOCaOTITypkrjhFQz1BaF7oGyW8mVcuTBRPYRcFdb6m9T/tT6DO 1uBSBwAR8M7yAhJ0M1DZ7WOaaDTNpWtHcAmkMh4yLhRFbZKfp8mLrXptrtO/F4kPj1Sg r8mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706775294; x=1707380094; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uXX6851uCjtiZLhZz0jMQytjWVPIVDPo0oUudLzGlF4=; b=dONfjgOhxjArdyKd323HNa8mZR4RuncVvdmfOH1V4gObiK03IUwrLvF3Lm73GMYreH C0gtEyAcrdyAn6/c1CCstwsGGJg96mtarTcrPwbuqFNE/fCBIJ7q5IINtTkFqJHHtmN3 pENBOmXTlLqQW5dq54wWf6vv7hcvI3JSgyzrDf52aEUycjL889FLcQLth+wVlrNSEIrk MshujEFNrBGtO0FagieT9d9KhHSZDj9Au5nHIhqLWm0KEwDwfCGJFap6oRInhebfNlQh EjtPSBMeK0gEn7TtKevcx/BAbRaTBT8S/NtfQHn3vBvln5Yi0K6suO48zc1m/ZMy3X5n RxbA== X-Gm-Message-State: AOJu0Yyc97C21UXRfYoESoTDliRnnCedT2ruL98gRwW6BeRmGuWxo1x8 oCyiP6TnlxUgM2S1aEWi+5956l547tAb8ashvjDclB+/fLZY1j+4mqpUfLgFew== X-Google-Smtp-Source: AGHT+IEkjzxS2zne3m7X6CWeM1TzwLvKuAUxIIpsXH4W91koqNYL/oKEce9niECpnSm7Ha9IyULh2w== X-Received: by 2002:a05:600c:2943:b0:40f:b456:6877 with SMTP id n3-20020a05600c294300b0040fb4566877mr3106061wmd.18.1706775294283; Thu, 01 Feb 2024 00:14:54 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUNg7/nooxIE2+n8r7M2gx0v35/gSb2/6HKOA2x+aPjot/a+czV56G/YcuDy3Y1R5MhjEsIgncVkuM0SseNv73Mo4YtxLX4AtChf+x8fbhBuY8YJg35bbojzmWs2KaCPiXYwjVbLo1SkVnITW9LQru8P5fNII4c1Eq2bYckZwXyZ9Wuds1Vb34AINRE1ORoKcA/dHXtVxz81ddWNN68KDaOwGysrodv7d2nPkP/m9UXy+Gxgu3eU/oN1APyW9p2KHQ6QIIKnPefhYvYzboQ+PxXnnis/6b+6a3evNPMOpgEBAGSPWjD95l7xQ== Message-ID: <86b25777-788c-4b9a-8166-a6f8174bedc9@suse.com> Date: Thu, 1 Feb 2024 09:14:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v12 10/15] 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: <20240109215145.430207-1-stewart.hildebrand@amd.com> <20240109215145.430207-11-stewart.hildebrand@amd.com> <50e79338-b2fd-40e9-b754-4e725e27ceb3@suse.com> <48a16cb3-9cb9-4b7d-a950-f190a9a64bc2@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: <48a16cb3-9cb9-4b7d-a950-f190a9a64bc2@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.02.2024 05:50, Stewart Hildebrand wrote: > On 1/25/24 10:43, Jan Beulich wrote: >> On 09.01.2024 22:51, Stewart Hildebrand wrote: >>> --- a/xen/drivers/vpci/header.c >>> +++ b/xen/drivers/vpci/header.c >>> @@ -168,6 +168,9 @@ static void modify_decoding(const struct pci_dev *pdev, uint16_t cmd, >>> if ( !rom_only ) >>> { >>> pci_conf_write16(pdev->sbdf, PCI_COMMAND, cmd); >>> + /* Show DomU that we updated P2M */ >>> + header->guest_cmd &= ~PCI_COMMAND_MEMORY; >>> + header->guest_cmd |= cmd & PCI_COMMAND_MEMORY; >>> header->bars_mapped = map; >>> } >> >> I don't follow what the comment means to say. The bit in question has no >> real connection to the P2M, and the guest also may have no notion of the >> underlying hypervisor's internals. Likely connected to ... > > Indeed. If the comment survives to v13, I'll update it to: > > /* Now that we updated P2M, show DomU change to PCI_COMMAND_MEMORY */ > >> >>> @@ -524,9 +527,26 @@ static void cf_check cmd_write( >>> { >>> struct vpci_header *header = data; >>> >>> + if ( !is_hardware_domain(pdev->domain) ) >>> + { >>> + const struct vpci *vpci = pdev->vpci; >>> + >>> + if ( (vpci->msi && vpci->msi->enabled) || >>> + (vpci->msix && vpci->msix->enabled) ) >>> + cmd |= PCI_COMMAND_INTX_DISABLE; >>> + >>> + /* >>> + * Do not show change to PCI_COMMAND_MEMORY bit until we finish >>> + * modifying P2M mappings. >>> + */ >>> + header->guest_cmd = (cmd & ~PCI_COMMAND_MEMORY) | >>> + (header->guest_cmd & PCI_COMMAND_MEMORY); >>> + } >> >> ... the comment here, but then shouldn't it be that the guest can't even >> issue a 2nd cfg space access until the present write has been carried out? >> Otherwise I'd be inclined to claim that such a partial update is unlikely >> to be spec-conformant. > > Due to the raise_softirq() call added in > > 3e568fa9e19c ("vpci: fix deferral of long operations") > > my current understanding is: when the guest toggles memory decoding, the guest vcpu doesn't resume execution until vpci_process_pending() and modify_decoding() have finished. So I think the guest should see a consistent state of the register, unless it was trying to read from a different vcpu than the one doing the writing. > > Regardless, if the guest did have an opportunity to successfully read the partially updated state of the register, I'm not really spotting what part of the spec that would be a violation of. PCIe 6.1 has this description regarding the bit: "When this bit is Set" and "When this bit is Clear" the device will decode (or not) memory accesses. The spec doesn't seem to distinguish whether the host or the device itself is the one to set/clear the bit. One might even try to argue the opposite: allowing the bit to be toggled before the device reflects the change would be a violation of spec. Since the spec is ambiguous in this regard, I don't think either argument is particularly strong. > > Chesterton's fence: the logic for deferring the update of PCI_COMMAND_MEMORY in guest_cmd was added between v10 and v11 of this series. I went back to look at the review comments on v10 [1], but the rationale is still not entirely clear to me. Indeed. The only sentence possibly hinting in such a direction would imo have been "I'm kind of unsure whether we want to fake the guest view by returning what the guest writes." It's unclear to me whether it really was meant that way. > At the end of the day, with the information I have at hand, I suspect it would be fine either way (whether updating guest_cmd is deferred or not). If no other info comes to light, I'm leaning toward not deferring because it would be simpler to update the bit right away in cmd_write(). I'm not sure it would be fine either way. Config space writes aren't posted writes, so they complete synchronously. IOW whatever internal state updates are needed in the device, they ought to have finished by the time the write completes. > [1] https://lore.kernel.org/xen-devel/ZVy73iJ3E8nJHvgf@macbook.local/ > >>[...] >>> --- 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; >>> + } >> >> ... the similar code here has it. >> >> In both cases, is it really appropriate to set the bit in guest view? > > I added this based on Roger's comment at [2]. Roger, what do you think? I don't believe QEMU updates the guest view in this manner. > > [2] https://lore.kernel.org/xen-devel/ZLqI65gmNj1XDBm4@MacBook-Air-de-Roger.local/ Leaving this for Roger to answer. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 08:15:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 08:15:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674241.1049065 (Exim 4.92) (envelope-from ) id 1rVSE7-0000Ed-Ba; Thu, 01 Feb 2024 08:15:15 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674241.1049065; Thu, 01 Feb 2024 08:15: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 1rVSE7-0000EW-7r; Thu, 01 Feb 2024 08:15:15 +0000 Received: by outflank-mailman (input) for mailman id 674241; Thu, 01 Feb 2024 08:15: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 1rVSE5-0008Oo-Pi for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 08:15:13 +0000 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [2a00:1450:4864:20::134]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 04cf22e6-c0da-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 09:15:11 +0100 (CET) Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-51124d43943so908980e87.2 for ; Thu, 01 Feb 2024 00:15:12 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id r17-20020a05600c459100b0040e527602c8sm3658249wmo.9.2024.02.01.00.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 00:15: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: 04cf22e6-c0da-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706775311; x=1707380111; 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=ftZj8xWkxeuKAOmzAYbWpkD03g2lwYFka9yLaabGBYU=; b=fl2m96rzMgAtO6uVBnzWIazZuyEM4Mvjy0Smj8Irzbap8i3/caM+0FjUEeMRgoyCDW iduIKdw2FiyhEWuSbC570BF4Cx+547z3o6mb1UJBpWcg2i1pSSy3yGzaouU2dUrEC90t vwJ4kBC+Cn6zj+RG39PVFWXC3pPe8cgL6yMZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706775311; x=1707380111; 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=ftZj8xWkxeuKAOmzAYbWpkD03g2lwYFka9yLaabGBYU=; b=pC/idycX5XQewvJK0xOZ2HX2luKCIHsrAH/y/kHKh82ZAlrkkmvVk6qVlOgKXEABD5 g7L/5rP0EKmC1YwQyv0DhiIUfdJeLiF8T0X5Ymx3/lPV5FYRSOBT6mQpWz+IYQiNMbAW kZPgYr5ykuY0hGN4EoJCdSqNB3JDygVKoxHUcxqQLwhL6By3bkOdWxg5Kd/nNx6M3b/2 zLZx9Z6tRBytwupGWPBIYI5pxtyE8tHQ4Qbzgoc/sROrB9ESPUShgEhBczf7fAIz0piy 2WLwEhjYujBfo0QU4sOItoXbhkoGsIV/+FkCc2tQwPmmWC2lxm4j/9KnG2Os2v8uKNsb GV3g== X-Gm-Message-State: AOJu0YwmkdXlTTp5InqrYGXnr5qX29zKQeh/enKQ5+iyluTnBWsuP2Px XkTVaUIi3xCUHzSmeDT3RY5mYbCuUEwlViADnZbJL05yec0nUts8ESiQaREUabAjPiI4iL40NrJ S X-Google-Smtp-Source: AGHT+IE8gLuXy+MPg1izu/6bIhKWak2wRqZet0KZ2tIQTi7ixhztfq33TeOjjIOuHvBuVum5CAKS/Q== X-Received: by 2002:ac2:5fcb:0:b0:511:8a1:4e08 with SMTP id q11-20020ac25fcb000000b0051108a14e08mr1097492lfg.9.1706775311520; Thu, 01 Feb 2024 00:15:11 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCU72vY78WMM5Oc05nOMgQHKUahgsw8cAJB74JwC997R/ve+rpdCHw2Iuue/6RSs2TuwxkFyU6X3WUykkvh4w0g/5hUjkUAnJDSwRTmwim84+je9wcTm Date: Thu, 1 Feb 2024 09:15:10 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu Subject: Re: [PATCH] shim: avoid building of vendor IOMMU code Message-ID: References: <062053aa-455e-43d6-bc11-e25dc8052878@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <062053aa-455e-43d6-bc11-e25dc8052878@suse.com> On Thu, Feb 01, 2024 at 08:39:31AM +0100, Jan Beulich wrote: > There's no use for IOMMU code in the shim. Disable at least the vendor- > specific code, until eventually IOMMU code can be disabled altogether. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné That was easier than I expected :). Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Feb 01 08:21:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 08:21:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674246.1049075 (Exim 4.92) (envelope-from ) id 1rVSJu-0002OP-1i; Thu, 01 Feb 2024 08:21:14 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674246.1049075; Thu, 01 Feb 2024 08: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 1rVSJt-0002OI-V7; Thu, 01 Feb 2024 08:21:13 +0000 Received: by outflank-mailman (input) for mailman id 674246; Thu, 01 Feb 2024 08:16: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 1rVSF6-0000xF-3n for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 08:16:17 +0000 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 293a3220-c0da-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 09:16: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: 293a3220-c0da-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=oat2jhs3tfeuzhvy2ui5tmazwq.protonmail; t=1706775371; x=1707034571; bh=m5mnweclGAWQKNx6iCQLtjWxNRC7Y1HIkiDeF/KR1/M=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=GDQn/oHiMp5ogEXCNNEtTx9oWPyUfm9ZE3zaxJlI9up0b62tjRYzzzoRmM/tXHKLa AFEahWDJwSLIw0BBScC/DEt9ddcwFXI6B2KmvtYrXQ/2n9mG7BRitPEwxp6CRufEg/ Mr8HEl93tmo6V30acpctzIp/ueDvIFK9vaHxE3XPro00I0D4Y+Sxkh4IooOVYLZIG0 GhrmeYqmQ0HFa2O6mgUiriX81gctmWWpYVdwvGbQTLGBOJ9m5r2qoPoEd8alBikOZv C2H/nqesk62SQsucJooGgjudIB32BwxRhGfECHLBW7e51bWOXdB1rw5xT+f+ojFnim DbcO/B1jY5Q9Q== Date: Thu, 01 Feb 2024 08:16:05 +0000 To: "xen-devel@lists.xenproject.org" From: oxjo@proton.me Cc: "roger.pau@citrix.com" Subject: Issue iommu unrecognized on amd computer Message-ID: Feedback-ID: 99814252:user:proton MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8" This is a multi-part message in MIME format. --b1_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8 Content-Type: multipart/alternative; boundary="b2_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8" --b2_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksCgpGb2xsb3dpbmcgb3VyIGludGVyYWN0aW9uIG9uIG1hdHJpeCwgSSBzZW5kIHlvdSB0aGUg Ym9vdCBsb2cgYHhsIGRtZXNnYCBvdXRwdXQgb2YgbXkgY29tcHV0ZXIsIGJvb3Rpbmcgd2l0aCBg aW9tbXU9ZGVidWdgIG9wdGlvbnMgb24gbGludXggNi42LjEzLTIwMC5mYzM5LgoKTXkgaXNzdWUg aXMgZXZlcnl0aGluZyB3b3JrcyBvbiBxdWJlcyBvbiBteSB0aGlua3BhZCBMMTUgZ2VuIDQgd2l0 aCBBTUQgUnl6ZW4gNyBQcm8gNzczMFUsIGV4Y2VwdCBpb21tdS9hbWQtdmkuCkkgY2FuIGJvb3Qg YW5kIHVzZSBhIHZtIGJ1dCBubyBwY2kgcGFzc3Rocm91Z2guCgpJIHRyaWVkIHF1YmVzIDQuMiwg YmFyZSB4ZW4gMTcuMiwgeGVuIDE4IGFuZCBJIGFsd2F5cyBoYXZlIHRoZSBzYW1lIG1lc3NhZ2Vz IHlvdSBjYW4gc2VlIGluIHRoZSBsb2dzIHdpdGggSVZNRC4KCkknZCBiZSBncmF0ZWZ1bCBpZiB5 b3UgY2FuIHRlbGwgbWUgd2l0aGluIGEgd2VlayBpZiBpdCdzIGFuIGlzc3VlIHlvdSB0aGluayBj YW4gYmUgZGVhbHQgd2l0aCBvciBubyBzbyBJIGNhbiBkZWNpZGUgd2hhdCBJIGRvIHdpdGggdGhp cyBjb21wdXRlci4KCkJlc3QgcmVnYXJkcywKT3g= --b2_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7Ij5IaSw8L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkZvbGxvd2luZyBvdXIgaW50ZXJhY3Rp b24gb24gbWF0cml4LCBJIHNlbmQgeW91IHRoZSBib290IGxvZyBgeGwgZG1lc2dgIG91dHB1dCBv ZiBteSBjb21wdXRlciwgYm9vdGluZyB3aXRoIGBpb21tdT1kZWJ1Z2Agb3B0aW9ucyBvbiBsaW51 eCA2LjYuMTMtMjAwLmZjMzkuPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5NeSBpc3N1ZSBpcyBl dmVyeXRoaW5nIHdvcmtzIG9uIHF1YmVzIG9uIG15IHRoaW5rcGFkIEwxNSBnZW4gNCB3aXRoIEFN RCBSeXplbiA3Jm5ic3A7IFBybyA3NzMwVSwgZXhjZXB0IGlvbW11L2FtZC12aS48L2Rpdj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi PkkgY2FuIGJvb3QgYW5kIHVzZSBhIHZtIGJ1dCBubyBwY2kgcGFzc3Rocm91Z2guPC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7Ij5JIHRyaWVkIHF1YmVzIDQuMiwgYmFyZSB4ZW4gMTcuMiwgeGVuIDE4 IGFuZCBJIGFsd2F5cyBoYXZlIHRoZSBzYW1lIG1lc3NhZ2VzIHlvdSBjYW4gc2VlIGluIHRoZSBs b2dzIHdpdGggSVZNRC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkknZCBiZSBncmF0ZWZ1bCBp ZiB5b3UgY2FuIHRlbGwgbWUgd2l0aGluIGEgd2VlayBpZiBpdCdzIGFuIGlzc3VlIHlvdSB0aGlu ayBjYW4gYmUgZGVhbHQgd2l0aCBvciBubyBzbyBJIGNhbiBkZWNpZGUgd2hhdCBJIGRvIHdpdGgg dGhpcyBjb21wdXRlci48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPkJlc3QgcmVnYXJkcyw8L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPk94PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48YnI+PC9kaXY+DQo= --b2_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8-- --b1_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8 Content-Type: text/plain; name=boot.log Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=boot.log IFhlbiA0LjE4LjAKKFhFTikgWGVuIHZlcnNpb24gNC4xOC4wIChtb2NrYnVpbGRAKSAoZ2NjIChH Q0MpIDEzLjIuMSAyMDIzMTIwNSAoUmVkIEhhdCAxMy4yLjEtNikpIGRlYnVnPW4gV2VkIERlYyAx MyAxNzo1MDo0MiBVVEMgMjAyMwooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiAKKFhFTikgYnVpbGQt aWQ6IGVhNWQxOTYwYThkMDZmMzFiMDAwMzU1ZjQ2NjIxNjlmZTEyZDA5YTYKKFhFTikgQm9vdGxv YWRlcjogR1JVQiAyLjA2CihYRU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgbm8tcmVhbC1t b2RlIGVkZD1vZmYKKFhFTikgWGVuIGltYWdlIGxvYWQgYmFzZSBhZGRyZXNzOiAweGMxYTAwMDAw CihYRU4pIFZpZGVvIGluZm9ybWF0aW9uOgooWEVOKSAgVkdBIGlzIGdyYXBoaWNzIG1vZGUgMTky MHgxMDgwLCAzMiBicHAKKFhFTikgIFZCRS9EREMgbWV0aG9kczogbm9uZTsgRURJRCB0cmFuc2Zl ciB0aW1lOiAwIHNlY29uZHMKKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKKFhFTikgIEZvdW5kIDAg TUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDEgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMK KFhFTikgQ1BVIFZlbmRvcjogQU1ELCBGYW1pbHkgMjUgKDB4MTkpLCBNb2RlbCA4MCAoMHg1MCks IFN0ZXBwaW5nIDAgKHJhdyAwMGE1MGYwMCkKKFhFTikgRW5hYmxpbmcgU3VwZXJ2aXNvciBTaGFk b3cgU3RhY2tzCihYRU4pICAgLSBEaXNhYmxpbmcgUFYzMiBkdWUgdG8gQ0VUCihYRU4pIEVGSSBS QU0gbWFwOgooWEVOKSAgWzAwMDAwMDAwMDAwMDAwMDAsIDAwMDAwMDAwMDAwOWVmZmZdICh1c2Fi bGUpCihYRU4pICBbMDAwMDAwMDAwMDA5ZjAwMCwgMDAwMDAwMDAwMDA5ZmZmZl0gKHJlc2VydmVk KQooWEVOKSAgWzAwMDAwMDAwMDAxMDAwMDAsIDAwMDAwMDAwMDliZmZmZmZdICh1c2FibGUpCihY RU4pICBbMDAwMDAwMDAwOWMwMDAwMCwgMDAwMDAwMDAwOWRiMGZmZl0gKHJlc2VydmVkKQooWEVO KSAgWzAwMDAwMDAwMDlkYjEwMDAsIDAwMDAwMDAwMDllZmZmZmZdICh1c2FibGUpCihYRU4pICBb MDAwMDAwMDAwOWYwMDAwMCwgMDAwMDAwMDAwOWYwZWZmZl0gKEFDUEkgTlZTKQooWEVOKSAgWzAw MDAwMDAwMDlmMGYwMDAsIDAwMDAwMDAwYzJkNTdmZmZdICh1c2FibGUpCihYRU4pICBbMDAwMDAw MDBjMmQ1ODAwMCwgMDAwMDAwMDBjOGY1N2ZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAw YzhmNTgwMDAsIDAwMDAwMDAwYzlmNTdmZmZdIChBQ1BJIE5WUykKKFhFTikgIFswMDAwMDAwMGM5 ZjU4MDAwLCAwMDAwMDAwMGM5ZmQ3ZmZmXSAoQUNQSSBkYXRhKQooWEVOKSAgWzAwMDAwMDAwYzlm ZDgwMDAsIDAwMDAwMDAwYzlmZDlmZmZdICh1c2FibGUpCihYRU4pICBbMDAwMDAwMDBjOWZkYTAw MCwgMDAwMDAwMDBjOWZmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwY2EwMDAwMDAs IDAwMDAwMDAwY2JmZmZmZmZdICh1c2FibGUpCihYRU4pICBbMDAwMDAwMDBjYzAwMDAwMCwgMDAw MDAwMDBjZGZmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwY2YwMDAwMDAsIDAwMDAw MDAwY2ZmZmZmZmZdIChyZXNlcnZlZCkKKFhFTikgIFswMDAwMDAwMGY4MDAwMDAwLCAwMDAwMDAw MGZiZmZmZmZmXSAocmVzZXJ2ZWQpCihYRU4pICBbMDAwMDAwMDBmZGMwMDAwMCwgMDAwMDAwMDBm ZGNmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwZmVkODAwMDAsIDAwMDAwMDAwZmVk ODBmZmZdIChyZXNlcnZlZCkKKFhFTikgIFswMDAwMDAwMTAwMDAwMDAwLCAwMDAwMDAwZmVlMmZm ZmZmXSAodXNhYmxlKQooWEVOKSAgWzAwMDAwMDBmZWUzMDAwMDAsIDAwMDAwMDEwMmZmZmZmZmZd IChyZXNlcnZlZCkKKFhFTikgQUNQSTogUlNEUCBDOUZENzAxNCwgMDAyNCAocjIgTEVOT1ZPKQoo WEVOKSBBQ1BJOiBYU0RUIEM5RkQ1MTg4LCAwMTA0IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDEx MzAgUFRFQyAgICAgICAgMikKKFhFTikgQUNQSTogRkFDUCBDMzk2NDAwMCwgMDExNCAocjYgTEVO T1ZPIFRQLVIyNSAgICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IERTRFQgQzM5 NEMwMDAsIDEyNzkxIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgSU5UTCAyMDE4MDMxMykK KFhFTikgQUNQSTogRkFDUyBDOURGODAwMCwgMDA0MAooWEVOKSBBQ1BJOiBTU0RUIEM1RTc0MDAw LCAwMEEyIChyMSBMRU5PVk8gUElEMFNzZHQgICAgICAgIDEgSU5UTCAyMDE4MDMxMykKKFhFTikg QUNQSTogU1NEVCBDNUU3MzAwMCwgMDc1MiAocjEgTEVOT1ZPIFVzYkNUYWJsICAgICAgICAxIElO VEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzVFNjYwMDAsIDczNDUgKHIyIExFTk9WTyBU UC1SMjUgICAgICAgICAgMiBNU0ZUICAyMDAwMDAyKQooWEVOKSBBQ1BJOiBNU0RNIEM1QjdCMDAw LCAwMDU1IChyMyBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikg QUNQSTogQkFUQiBDNUI2NjAwMCwgMDA0QSAocjIgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBU RUMgICAgICAgIDIpCihYRU4pIEFDUEk6IEhQRVQgQzM5NjMwMDAsIDAwMzggKHIxIExFTk9WTyBU UC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBBUElDIEMzOTYyMDAw LCAwMTM4IChyMiBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikg QUNQSTogTUNGRyBDMzk2MTAwMCwgMDAzQyAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBU RUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNCU1QgQzM5NjAwMDAsIDAwMzAgKHIxIExFTk9WTyBU UC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBXU01UIEMzOTVGMDAw LCAwMDI4IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikg QUNQSTogVkZDVCBDMzkzRTAwMCwgRDg4NCAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBU RUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNTRFQgQzM5MzgwMDAsIDUzNTQgKHIyIExFTk9WTyBU UC1SMjUgICAgICAgICAgMSBBTUQgICAgICAgICAxKQooWEVOKSBBQ1BJOiBDUkFUIEMzOTM3MDAw LCAwRUMwIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikg QUNQSTogQ0RJVCBDMzkzNjAwMCwgMDAyOSAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBU RUMgICAgICAgIDIpCihYRU4pIEFDUEk6IEZQRFQgQzVCNjcwMDAsIDAwMzQgKHIxIExFTk9WTyBU UC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBTU0RUIEMzOTM1MDAw LCAwMTQ5IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4MDMxMykKKFhFTikg QUNQSTogU1NEVCBDMzkzMzAwMCwgMTRDMyAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAgICAxIElO VEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzM5MzEwMDAsIDE1QTggKHIxIExFTk9WTyBU UC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBBQ1BJOiBTU0RUIEMzOTJEMDAw LCAzQjBFIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4MDMxMykKKFhFTikg QUNQSTogQkdSVCBDMzkyQzAwMCwgMDAzOCAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBU RUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNTRFQgQzM5MkIwMDAsIDAyNEQgKHIxIExFTk9WTyBU UC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBBQ1BJOiBTU0RUIEMzOTI5MDAw LCAxNEM0IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4MDMxMykKKFhFTikg QUNQSTogU1NEVCBDMzkyODAwMCwgMEFCNyAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAgICAxIElO VEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFVFRkkgQzlERjcwMDAsIDAwQzYgKHIxIExFTk9WTyBU UC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBJVlJTIEMzOTI3MDAw LCAwMUU0IChyMiBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikg QUNQSTogU1NEVCBDNUU3MjAwMCwgMDA5MCAocjEgTEVOT1ZPIFRQLVIyNSAgICAgICAgICAxIElO VEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzVFNzEwMDAsIDA5OEQgKHIxIExFTk9WTyBU UC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBTeXN0ZW0gUkFNOiA2NDMwMk1C ICg2NTg0NTQ3NmtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQKKFhFTikgRmFr aW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDBmZWUzMDAwMDAKKFhFTikgRG9t YWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweDAwMDAw MDAwZDAwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAyMDEwMDAsIHVzaW5nIDgxMjhrLCB0 b3RhbCA4MTI4awooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTkyMHgxMDgweDMyLCBsaW5lbGVuZ3Ro PTc2ODAsIGZvbnQgOHgxNgooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6ZT04Ojg6ODo4LCBz aGlmdD0yNDoxNjo4OjAKKFhFTikgU01CSU9TIDMuMyBwcmVzZW50LgooWEVOKSBVc2luZyBBUElD IGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4NDA4ICgzMiBi aXRzKQooWEVOKSBBQ1BJOiB2NSBTTEVFUCBJTkZPOiBjb250cm9sWzE6MF0sIHN0YXR1c1sxOjBd CihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6NDA0LDE6MF0sIHBtMXhfZXZ0WzE6 NDAwLDE6MF0KKFhFTikgQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBpbiBGQURU IC0gYzlkZjgwMDAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzIKKFhFTikgQUNQSTogICAgICAg ICAgICAgd2FrZXVwX3ZlY1tjOWRmODAwY10sIHZlY19zaXplWzIwXQooWEVOKSBPdmVycmlkaW5n IEFQSUMgZHJpdmVyIHdpdGggYmlnc21wCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgyMF0gYWRk cmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGljX2lkIDMy LCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4pIEFDUEk6IElP QVBJQyAoaWRbMHgyMV0gYWRkcmVzc1sweGZlYzAxMDAwXSBnc2lfYmFzZVsyNF0pCihYRU4pIElP QVBJQ1sxXTogYXBpY19pZCAzMywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAxMDAwLCBHU0kg MjQtNTUKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9iYWxfaXJx IDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9i YWxfaXJxIDkgbG93IGxldmVsKQooWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDQzNTM4MjEwIGJhc2U6 IDB4ZmVkMDAwMDAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBmODAwMDAw MCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBmODAw MDAwMCByZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNpbmcgTUNGRyBmb3Igc2VnbWVudCAw MDAwIGJ1cyAwMC0zZgooWEVOKSBBQ1BJOiBCR1JUOiBpbnZhbGlkYXRpbmcgdjEgaW1hZ2UgYXQg MHhiZDY1NjAxOAooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24g aW5mb3JtYXRpb24KKFhFTikgU01QOiBBbGxvd2luZyAxNiBDUFVzICgwIGhvdHBsdWcgQ1BVcykK KFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAzMjcyIE1TSS9NU0ktWAooWEVOKSBDUFUwOiAxNjAw IC4uLiAyMDAwIE1IegooWEVOKSB4c3RhdGU6IHNpemU6IDB4OTg4IGFuZCBzdGF0ZXM6IDB4MjA3 CihYRU4pIENQVTA6IEFNRCBGYW0xOWggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZAoo WEVOKSBWdWxuZXJhYmxlIHRvIFNSU08sIHdpdGhvdXQgc3VpdGFibGUgbWljcm9jb2RlIHRvIG1p dGlnYXRlCihYRU4pIFNwZWN1bGF0aXZlIG1pdGlnYXRpb24gZmFjaWxpdGllczoKKFhFTikgICBI YXJkd2FyZSBoaW50czogU1RJQlBfQUxXQVlTIElCUlNfRkFTVCBJQlJTX1NBTUVfTU9ERQooWEVO KSAgIEhhcmR3YXJlIGZlYXR1cmVzOiBJQlBCIElCUlMgU1RJQlAgU1NCRCBQU0ZECihYRU4pICAg Q29tcGlsZWQtaW4gc3VwcG9ydDogSU5ESVJFQ1RfVEhVTksgU0hBRE9XX1BBR0lORwooWEVOKSAg IFhlbiBzZXR0aW5nczogQlRJLVRodW5rIEpNUCwgU1BFQ19DVFJMOiBJQlJTKyBTVElCUCsgU1NC RC0gUFNGRC0sIE90aGVyOiBJQlBCLWN0eHQgQlJBTkNIX0hBUkRFTgooWEVOKSAgIFN1cHBvcnQg Zm9yIEhWTSBWTXM6IE1TUl9TUEVDX0NUUkwgTVNSX1ZJUlRfU1BFQ19DVFJMIFJTQgooWEVOKSAg IFN1cHBvcnQgZm9yIFBWIFZNczogTm9uZQooWEVOKSAgIFhQVEkgKDY0LWJpdCBQViBvbmx5KTog RG9tMCBkaXNhYmxlZCwgRG9tVSBkaXNhYmxlZCAod2l0aG91dCBQQ0lEKQooWEVOKSAgIFBWIEwx VEYgc2hhZG93aW5nOiBEb20wIGRpc2FibGVkLCBEb21VIGRpc2FibGVkCihYRU4pIFVzaW5nIHNj aGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgcmV2MiAoY3JlZGl0MikKKFhFTikgSW5pdGlh bGl6aW5nIENyZWRpdDIgc2NoZWR1bGVyCihYRU4pICBsb2FkX3ByZWNpc2lvbl9zaGlmdDogMTgK KFhFTikgIGxvYWRfd2luZG93X3NoaWZ0OiAzMAooWEVOKSAgdW5kZXJsb2FkX2JhbGFuY2VfdG9s ZXJhbmNlOiAwCihYRU4pICBvdmVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogLTMKKFhFTikgIHJ1 bnF1ZXVlcyBhcnJhbmdlbWVudDogc29ja2V0CihYRU4pICBjYXAgZW5mb3JjZW1lbnQgZ3JhbnVs YXJpdHk6IDEwbXMKKFhFTikgbG9hZCB0cmFja2luZyB3aW5kb3cgbGVuZ3RoIDEwNzM3NDE4MjQg bnMKKFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgRGV0ZWN0ZWQg MTk5Ni4yNTkgTUh6IHByb2Nlc3Nvci4KKFhFTikgRnJlZWQgMTAyMGtCIHVudXNlZCBCU1MgbWVt b3J5CihYRU4pIGFsdCB0YWJsZSBmZmZmODJkMDQwNDViZDk4IC0+IGZmZmY4MmQwNDA0NjkyYTgK KFhFTikgQU1ELVZpOiBJT01NVSBFeHRlbmRlZCBGZWF0dXJlczoKKFhFTikgLSBQZXJpcGhlcmFs IFBhZ2UgU2VydmljZSBSZXF1ZXN0CihYRU4pIC0geDJBUElDCihYRU4pIC0gTlggYml0CihYRU4p IC0gSW52YWxpZGF0ZSBBbGwgQ29tbWFuZAooWEVOKSAtIEd1ZXN0IEFQSUMKKFhFTikgLSBQZXJm b3JtYW5jZSBDb3VudGVycwooWEVOKSAtIEhvc3QgQWRkcmVzcyBUcmFuc2xhdGlvbiBTaXplOiAw eDIKKFhFTikgLSBHdWVzdCBBZGRyZXNzIFRyYW5zbGF0aW9uIFNpemU6IDAKKFhFTikgLSBHdWVz dCBDUjMgUm9vdCBUYWJsZSBMZXZlbDogMHgxCihYRU4pIC0gTWF4aW11bSBQQVNJRDogMHhmCihY RU4pIC0gU01JIEZpbHRlciBSZWdpc3RlcjogMHgxCihYRU4pIC0gU01JIEZpbHRlciBSZWdpc3Rl ciBDb3VudDogMHgxCihYRU4pIC0gR3Vlc3QgVmlydHVhbCBBUElDIE1vZGVzOiAweDEKKFhFTikg LSBEdWFsIFBQUiBMb2c6IDB4MgooWEVOKSAtIER1YWwgRXZlbnQgTG9nOiAweDIKKFhFTikgLSBV c2VyIC8gU3VwZXJ2aXNvciBQYWdlIFByb3RlY3Rpb24KKFhFTikgLSBEZXZpY2UgVGFibGUgU2Vn bWVudGF0aW9uOiAweDMKKFhFTikgLSBQUFIgTG9nIE92ZXJmbG93IEVhcmx5IFdhcm5pbmcKKFhF TikgLSBQUFIgQXV0b21hdGljIFJlc3BvbnNlCihYRU4pIC0gTWVtb3J5IEFjY2VzcyBSb3V0aW5n IGFuZCBDb250cm9sOiAwCihYRU4pIC0gQmxvY2sgU3RvcE1hcmsgTWVzc2FnZQooWEVOKSAtIFBl cmZvcm1hbmNlIE9wdGltaXphdGlvbgooWEVOKSAtIE1TSSBDYXBhYmlsaXR5IE1NSU8gQWNjZXNz CihYRU4pIC0gR3Vlc3QgSS9PIFByb3RlY3Rpb24KKFhFTikgLSBFbmhhbmNlZCBQUFIgSGFuZGxp bmcKKFhFTikgLSBBdHRyaWJ1dGUgRm9yd2FyZAooWEVOKSAtIEludmFsaWRhdGUgSU9UTEIgVHlw ZQooWEVOKSAtIFZNIFRhYmxlIFNpemU6IDAKKFhFTikgLSBHdWVzdCBBY2Nlc3MgQml0IFVwZGF0 ZSBEaXNhYmxlCihYRU4pIEFNRC1WaTogV2FybmluZzogSVZNRDogW2M5ZjFjMDAwLGM5ZjQyMDAw KSBpcyBub3QgKGVudGlyZWx5KSBpbiByZXNlcnZlZCBtZW1vcnkKKFhFTikgQU1ELVZpOiBFcnJv cjogSVZNRDogcGFnZSBhdCBjOWYxYzAwMCBjYW4ndCBiZSBjb252ZXJ0ZWQKKFhFTikgQU1ELVZp OiBFcnJvciBpbml0aWFsaXphdGlvbgooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZGlzYWJsZWQK KFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgUGh5c2ljYWwuICBVc2luZyAyIEkvTyBBUElDcwoo WEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sgbWV0aG9k CihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9 LTEKKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIEhWTTogQVNJ RHMgZW5hYmxlZC4KKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6CihYRU4p ICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSAgLSBMYXN0IEJyYW5jaCBSZWNvcmQg KExCUikgVmlydHVhbGlzYXRpb24KKFhFTikgIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZNRVhJVAoo WEVOKSAgLSBWTUNCIENsZWFuIEJpdHMKKFhFTikgIC0gRGVjb2RlQXNzaXN0cwooWEVOKSAgLSBW aXJ0dWFsIFZNTE9BRC9WTVNBVkUKKFhFTikgIC0gVmlydHVhbCBHSUYKKFhFTikgIC0gUGF1c2Ut SW50ZXJjZXB0IEZpbHRlcgooWEVOKSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyIFRocmVzaG9s ZAooWEVOKSAgLSBUU0MgUmF0ZSBNU1IKKFhFTikgIC0gTlBUIFN1cGVydmlzb3IgU2hhZG93IFN0 YWNrCihYRU4pICAtIE1TUl9TUEVDX0NUUkwgdmlydHVhbGlzYXRpb24KKFhFTikgSFZNOiBTVk0g ZW5hYmxlZAooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBkZXRlY3Rl ZAooWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCCihYRU4pIGFsdCB0YWJs ZSBmZmZmODJkMDQwNDViZDk4IC0+IGZmZmY4MmQwNDA0NjkyYTgKKFhFTikgQnJvdWdodCB1cCAx NiBDUFVzCihYRU4pIFNjaGVkdWxpbmcgZ3JhbnVsYXJpdHk6IGNwdSwgMSBDUFUgcGVyIHNjaGVk LXJlc291cmNlCihYRU4pIEluaXRpYWxpemluZyBDcmVkaXQyIHNjaGVkdWxlcgooWEVOKSAgbG9h ZF9wcmVjaXNpb25fc2hpZnQ6IDE4CihYRU4pICBsb2FkX3dpbmRvd19zaGlmdDogMzAKKFhFTikg IHVuZGVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogMAooWEVOKSAgb3ZlcmxvYWRfYmFsYW5jZV90 b2xlcmFuY2U6IC0zCihYRU4pICBydW5xdWV1ZXMgYXJyYW5nZW1lbnQ6IHNvY2tldAooWEVOKSAg Y2FwIGVuZm9yY2VtZW50IGdyYW51bGFyaXR5OiAxMG1zCihYRU4pIGxvYWQgdHJhY2tpbmcgd2lu ZG93IGxlbmd0aCAxMDczNzQxODI0IG5zCihYRU4pIEFkZGluZyBjcHUgMCB0byBydW5xdWV1ZSAw CihYRU4pICBGaXJzdCBjcHUgb24gcnVucXVldWUsIGFjdGl2YXRpbmcKKFhFTikgQWRkaW5nIGNw dSAxIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSAyIHRvIHJ1bnF1ZXVlIDAKKFhFTikg QWRkaW5nIGNwdSAzIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA0IHRvIHJ1bnF1ZXVl IDAKKFhFTikgQWRkaW5nIGNwdSA1IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA2IHRv IHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA3IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5n IGNwdSA4IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA5IHRvIHJ1bnF1ZXVlIDAKKFhF TikgQWRkaW5nIGNwdSAxMCB0byBydW5xdWV1ZSAwCihYRU4pIEFkZGluZyBjcHUgMTEgdG8gcnVu cXVldWUgMAooWEVOKSBBZGRpbmcgY3B1IDEyIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNw dSAxMyB0byBydW5xdWV1ZSAwCihYRU4pIEFkZGluZyBjcHUgMTQgdG8gcnVucXVldWUgMAooWEVO KSBBZGRpbmcgY3B1IDE1IHRvIHJ1bnF1ZXVlIDAKKFhFTikgbWNoZWNrX3BvbGw6IE1hY2hpbmUg Y2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSBOWCAoRXhlY3V0ZSBEaXNhYmxlKSBw cm90ZWN0aW9uIGFjdGl2ZQooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDEwOTYgUElSUXMKKFhFTikg KioqIEJ1aWxkaW5nIGEgUFYgRG9tMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxz YiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIGxzYiwgcGFkZHIgMHgxMDAw MDAwIC0+IDB4NGEwMDAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6CihYRU4p ICBEb20wIGFsbG9jLjogICAwMDAwMDAwYzMwMDAwMDAwLT4wMDAwMDAwYzM4MDAwMDAwICgxNjIx OTU2NCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiByYW1kaXNrOiAwMDAwMDAw ZmVhZjA1MDAwLT4wMDAwMDAwZmVlMWZmMjhlCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFSUkFOR0VN RU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZmZmY4NGEw MDAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogMDAwMDAwODAwMDAwMDAwMC0+MDAwMDAwODAwN2Mx ODUzOAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NGEwMDAwMC0+ZmZmZmZmZmY4NGEw MDRiOAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NGEwMTAwMC0+ZmZmZmZmZmY4NGEy YTAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NGEyYTAwMC0+ZmZmZmZmZmY4NGEy YjAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZmZmY4NGMw MDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4M2FlNzRjMAooWEVOKSBEb20wIGhh cyBtYXhpbXVtIDE2IFZDUFVzCihYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2aXJxIHRocmVzaG9s ZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU0gaW4gYmFja2dy b3VuZAooWEVOKSBTdGQuIExvZ2xldmVsOiBFcnJvcnMsIHdhcm5pbmdzIGFuZCBpbmZvCihYRU4p IEd1ZXN0IExvZ2xldmVsOiBOb3RoaW5nIChSYXRlLWxpbWl0ZWQ6IEVycm9ycyBhbmQgd2Fybmlu Z3MpCihYRU4pIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAqKiogU2Vy aWFsIGlucHV0IHRvIERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlu cHV0KQooWEVOKSBGcmVlZCA2NDhrQiBpbml0IG1lbW9yeQo= --b1_ahePdPP8ZPOBcsnbMP4jUdSkh5Jox7jBC4XyO2W8-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 08:40:01 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 08:40:01 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674256.1049086 (Exim 4.92) (envelope-from ) id 1rVSbz-000576-KK; Thu, 01 Feb 2024 08:39:55 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674256.1049086; Thu, 01 Feb 2024 08:39: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 1rVSbz-00056z-GA; Thu, 01 Feb 2024 08:39:55 +0000 Received: by outflank-mailman (input) for mailman id 674256; Thu, 01 Feb 2024 08:39: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 1rVSby-00056t-4C for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 08:39:54 +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 76f01adc-c0dd-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 09:39:53 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40e80046246so3010285e9.1 for ; Thu, 01 Feb 2024 00:39:51 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id g10-20020a05600c4eca00b0040fbba734f3sm1082225wmq.34.2024.02.01.00.39.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 00:39: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: 76f01adc-c0dd-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706776790; x=1707381590; 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=Mmx7Ge44ylq+xRaE54Mmi5lsueMZNlgqIRQYM/UNpUU=; b=OmNEBETwYjdQ78BY2VOaVyxirQZhsePrn9jIlvhcHMLq3qHpua71BUUKK9TolNJaIM ICUePWoYJ+sten497EIQhayU6+HzPM7RICgEDsW4dnkflBGpmjI0L98/8OM5R9RpzWOp b91TgB3ekalm0wqP8YgixA02jfs0HOW1UyL+g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706776790; x=1707381590; 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=Mmx7Ge44ylq+xRaE54Mmi5lsueMZNlgqIRQYM/UNpUU=; b=tp5nUovhg8hSheHR5aULhHepI1RkXg0+w1u9R0XWbIT3ObJCbZTMD19kYjfWYMC7PH GPQYZkx/36C5+AvHs+I537C67RkfTa+YyHBZ/HJip22L/PaR0YawnSXfujdReOpnDb0Y yUHCA1G3gJHbuboJd0rQGsyBJI0xPWxf3ZeNZs+3fk9RZqWPf8qur6Qm7DmyVbTFVFWV qX06nNDYcSZRD5Bg93gmakJ9XUMbU58ZFaJb8jBY98lQxyXlMKeQrE7hgEpmeE+xQrUL UxwpWBbmtgAhpiM39y+YIch72cdlQnHYrnJqPK4Ro/gzQfY3p42CrpBLMozgOyMnSO3B tJjA== X-Gm-Message-State: AOJu0Yx1Iuvv8F+cBwLosI7Z5gyqSPHt1gZ7DBrOVLNwfO0vkFGpXaVT rIELNccLVJDzAXL9wdk3+Hy0sdkWl9hoVkjsUQ8WGk1Bq86ciZiJSMqjcWkUMXE= X-Google-Smtp-Source: AGHT+IGW7bgbJkTrR4Yza/IRXj8QJZwTE7Cr91T4ok2nKqWk8e0wQ2sciL8gpCHIKiRmLekUEHkNew== X-Received: by 2002:a05:600c:1c9a:b0:40e:f972:9901 with SMTP id k26-20020a05600c1c9a00b0040ef9729901mr3736599wms.4.1706776790540; Thu, 01 Feb 2024 00:39:50 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXDCVhgfb0o24SN4Wqn/FgnWkJYm9QCYpD/ESYbFl4VjZTFA1lzb2EecVom9k5fEwfP12Y/uppYGzcffTRrzp/icQGv3HjGZpMbEHP1O0bmMpkENMmh/i5WpK5zIezuae0Uf4YZJFj/GIIpi8YgFkSb+ve1+U2VK0dRTY3tLYI0EKqJsftwJxoWx8X1Knfb8tnC76BuOBql1srwLsN7vGSl2wcbMkEqp6rlaRVuZC9dj8g2KKow5t0/nsSr8nJZlls/92TMW3QXD5Uc/pJNuCeeBPj2+nM9/cIi4ZkYdMgG2c7Y3W/85xx3atQ7NFnga1NjCNQMDhJbuqruZaGAYHg7aAFbNfLKQC7xPnI5wPmFp1E3D2qFqwlvqSIyLUOZrN5YudkUPsFIPL0Qk1faQOXY4FjKqsnSsDMGI58pczPV4freLpRkOBnJ+zblZe0frUgjrALk1NdUEoPj3Y9vKQ+JxYOJfr1AnKZs/vkDbp6joC8yuId8ZmXn+YeGnhlWwAZhccdcXntd3R0= Date: Thu, 1 Feb 2024 09:39:49 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Bjorn Helgaas 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 Message-ID: References: <20240131190014.GA593286@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240131190014.GA593286@bhelgaas> On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote: > On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote: > > On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote: > > > On Tue, Jan 30, 2024 at 10:07:36AM +0100, Roger Pau Monné wrote: > > > > On Mon, Jan 29, 2024 at 04:01:13PM -0600, Bjorn Helgaas wrote: > > > > > On Thu, Jan 25, 2024 at 07:17:24AM +0000, Chen, Jiqian wrote: > > > > > > On 2024/1/24 00:02, Bjorn Helgaas wrote: > > > > > > > On Tue, Jan 23, 2024 at 10:13:52AM +0000, Chen, Jiqian wrote: > > > > > > >> On 2024/1/23 07:37, Bjorn Helgaas wrote: > > > > > > >>> On Fri, Jan 05, 2024 at 02:22:17PM +0800, Jiqian Chen wrote: > > > > > > >>>> 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. > > > > > > >> ... > > > > > > > > > > > > > >>> I don't know enough about Xen to know why it needs the GSI in > > > > > > >>> userspace. Is this passthrough brand new functionality that can't be > > > > > > >>> done today because we don't expose the GSI yet? > > > > > > > > > > I assume this must be new functionality, i.e., this kind of > > > > > passthrough does not work today, right? > > > > > > > > > > > >> has ACPI support and is responsible for detecting and controlling > > > > > > >> the hardware, also it performs privileged operations such as the > > > > > > >> creation of normal (unprivileged) domains DomUs. When we give to a > > > > > > >> DomU direct access to a device, we need also to route the physical > > > > > > >> interrupts to the DomU. In order to do so Xen needs to setup and map > > > > > > >> the interrupts appropriately. > > > > > > > > > > > > > > What kernel interfaces are used for this setup and mapping? > > > > > > > > > > > > For passthrough devices, the setup and mapping of routing physical > > > > > > interrupts to DomU are done on Xen hypervisor side, hypervisor only > > > > > > need userspace to provide the GSI info, see Xen code: > > > > > > xc_physdev_map_pirq require GSI and then will call hypercall to pass > > > > > > GSI into hypervisor and then hypervisor will do the mapping and > > > > > > routing, kernel doesn't do the setup and mapping. > > > > > > > > > > So we have to expose the GSI to userspace not because userspace itself > > > > > uses it, but so userspace can turn around and pass it back into the > > > > > kernel? > > > > > > > > No, the point is to pass it back to Xen, which doesn't know the > > > > mapping between GSIs and PCI devices because it can't execute the ACPI > > > > AML resource methods that provide such information. > > > > > > > > The (Linux) kernel is just a proxy that forwards the hypercalls from > > > > user-space tools into Xen. > > > > > > But I guess Xen knows how to interpret a GSI even though it doesn't > > > have access to AML? > > > > On x86 Xen does know how to map a GSI into an IO-APIC pin, in order > > configure the RTE as requested. > > IIUC, mapping a GSI to an IO-APIC pin requires information from the > MADT. So I guess Xen does use the static ACPI tables, but not the AML > _PRT methods that would connect a GSI with a PCI device? Yes, Xen can parse the static tables, and knows the base GSI of IO-APICs from the MADT. > I guess this means Xen would not be able to deal with _MAT methods, > which also contains MADT entries? I don't know the implications of > this -- maybe it means Xen might not be able to use with hot-added > devices? It's my understanding _MAT will only be present on some very specific devices (IO-APIC or CPU objects). Xen doesn't support hotplug of IO-APICs, but hotplug of CPUs should in principle be supported with cooperation from the control domain OS (albeit it's not something that we tests on our CI). I don't expect however that a CPU object _MAT method will return IO APIC entries. > The tables (including DSDT and SSDTS that contain the AML) are exposed > to userspace via /sys/firmware/acpi/tables/, but of course that > doesn't mean Xen knows how to interpret the AML, and even if it did, > Xen probably wouldn't be able to *evaluate* it since that could > conflict with the host kernel's use of AML. Indeed, there can only be a single OSPM, and that's the dom0 OS (Linux in our context). Getting back to our context though, what would be a suitable place for exposing the GSI assigned to each device? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Feb 01 08:59:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 08:59:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674260.1049094 (Exim 4.92) (envelope-from ) id 1rVSun-00009K-3y; Thu, 01 Feb 2024 08:59:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674260.1049094; Thu, 01 Feb 2024 08:59: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 1rVSun-00009D-1A; Thu, 01 Feb 2024 08:59:21 +0000 Received: by outflank-mailman (input) for mailman id 674260; Thu, 01 Feb 2024 08:59: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 1rVSum-000097-0u for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 08:59:20 +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 2d97fc85-c0e0-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 09:59:17 +0100 (CET) Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-445-FwDJFd6PPhCM1yzxSKZkVQ-1; Thu, 01 Feb 2024 03:59:15 -0500 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-50ec9529001so559987e87.2 for ; Thu, 01 Feb 2024 00:59:14 -0800 (PST) Received: from [192.168.0.9] (ip-109-43-177-196.web.vodafone.de. [109.43.177.196]) by smtp.gmail.com with ESMTPSA id t12-20020a05600c450c00b0040e9f7308f4sm3803420wmo.10.2024.02.01.00.59.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 00:59: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: 2d97fc85-c0e0-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706777956; 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=46aTfHzOBMWuZA5PRKaMztJA+fyye2SIsD0CIZHrpW8=; b=OaK6VppTSmTVUr2WknCT2e3supYgKeVbVpAFUuOcr5kyqR+7wXQZszsyzR5qmHsw0Ul+kl PMRwUVqN2xMh8B5egG/SZaRRdK+NaYK6pvI4odvI7skaiwNJDUATBxlithSy7A/kngyXg6 fbHKWcf1eGQnkpeV7wY6d0wnMqdrd+Q= X-MC-Unique: FwDJFd6PPhCM1yzxSKZkVQ-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706777953; x=1707382753; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=46aTfHzOBMWuZA5PRKaMztJA+fyye2SIsD0CIZHrpW8=; b=brrNEeXOAnNn8vJ26b0J3odrllNSWHCo4RN/A/Hyxj8JhEeqEAq1USdwIee2eu4d3g SeBwxwg4Q11lvb0E73YVkHNH4frwHCFYTYCI6QkMTED1u/Cp2xR0ZGFB/Dym0P53WxeJ zuXpmZh0fkunUzIgH+uZazVhJCWc8sxJ52vHclB3I4V79Yuie/F8G02CK4Wz1SwY0iCA gDgzg/TboCh27kTTe7QJwTlOFyUa/+2TXEmPuKwU1OaDACTAnJs6A/BuXgfMMPcCKF1K Rxq1vHnEwtsvTGCIb1RnTxpmcDSWSk+RVf6v7KxjyjkD+RRn5eCGQOs1WL+DPebQunMJ amxQ== X-Gm-Message-State: AOJu0Yz9imYTTTGOxZ3B40BdqO+ukW5iqPWK0vj5dmcFFYdG6/o0pkxk nmy5UXexVFI2FRtqXNZx7BkMU3+78eZlEoC0air7HkxJ3z4I/zqH9NQjRg2BMyGl0dkh08rNmS7 ptfUzdEQSPVksRL9o6DWEhd5gsobqBhyn5bEF2cwdq8X3orsO0sp9wTBzV/QHn/g3 X-Received: by 2002:a19:ad0c:0:b0:511:319f:82eb with SMTP id t12-20020a19ad0c000000b00511319f82ebmr152468lfc.43.1706777953347; Thu, 01 Feb 2024 00:59:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IHxtZpmfE8n4eP1jKoWvPvn4IfLMH3obU6Ulatqlu1FlZMnyZlnKO4WsRVCTxkqqtQiWLrSIw== X-Received: by 2002:a19:ad0c:0:b0:511:319f:82eb with SMTP id t12-20020a19ad0c000000b00511319f82ebmr152423lfc.43.1706777953003; Thu, 01 Feb 2024 00:59:13 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2024 09:59:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 37/47] hw/net/lasi_i82596: Re-enable build To: David Woodhouse , qemu-devel@nongnu.org Cc: Richard Henderson , Beniamino Galvani , Peter Maydell , Strahinja Jankovic , Niek Linnenbank , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Andrew Jeffery , Joel Stanley , Igor Mitsyanko , Jean-Christophe Dubois , Andrey Smirnov , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Rob Herring , Subbaraya Sundeep , Jan Kiszka , Tyrone Ting , Hao Wu , Radoslaw Biernacki , Leif Lindholm , Marcin Juszkiewicz , "Edgar E. Iglesias" , Alistair Francis , Helge Deller , Paolo Bonzini , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , Song Gao , Thomas Huth , Laurent Vivier , Huacai Chen , Jiaxun Yang , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Aleksandar Rikalo , Aurelien Jarno , Jason Wang , Jia Liu , Stafford Horne , Mark Cave-Ayland , Nicholas Piggin , Daniel Henrique Barboza , David Gibson , Harsh Prateek Bora , Bin Meng , Palmer Dabbelt , Weiwei Li , Liu Zhiwei , Halil Pasic , Christian Borntraeger , Eric Farman , David Hildenbrand , Ilya Leoshkevich , Yoshinori Sato , Magnus Damm , Artyom Tarasenko , Stefano Stabellini , Anthony Perard , Paul Durrant , Max Filippov , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, David Woodhouse References: <20240126173228.394202-1-dwmw2@infradead.org> <20240126173228.394202-38-dwmw2@infradead.org> 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: <20240126173228.394202-38-dwmw2@infradead.org> 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: 7bit On 26/01/2024 18.25, David Woodhouse wrote: > From: David Woodhouse > > When converting to the shiny build-system-du-jour, a typo prevented the > last_i82596 driver from being built. Correct the config option name to > re-enable the build. And include "sysemu/sysemu.h" so it actually builds. > > Fixes: b1419fa66558 ("meson: convert hw/net") > Signed-off-by: David Woodhouse > --- > hw/net/lasi_i82596.c | 1 + > hw/net/meson.build | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/net/lasi_i82596.c b/hw/net/lasi_i82596.c > index 6a3147fe2d..09e830ba5f 100644 > --- a/hw/net/lasi_i82596.c > +++ b/hw/net/lasi_i82596.c > @@ -14,6 +14,7 @@ > #include "qapi/error.h" > #include "qemu/timer.h" > #include "hw/sysbus.h" > +#include "sysemu/sysemu.h" > #include "net/eth.h" > #include "hw/net/lasi_82596.h" > #include "hw/net/i82596.h" > diff --git a/hw/net/meson.build b/hw/net/meson.build > index 9afceb0619..2b426d3d5a 100644 > --- a/hw/net/meson.build > +++ b/hw/net/meson.build > @@ -33,7 +33,7 @@ system_ss.add(when: 'CONFIG_MARVELL_88W8618', if_true: files('mv88w8618_eth.c')) > system_ss.add(when: 'CONFIG_CADENCE', if_true: files('cadence_gem.c')) > system_ss.add(when: 'CONFIG_STELLARIS_ENET', if_true: files('stellaris_enet.c')) > system_ss.add(when: 'CONFIG_LANCE', if_true: files('lance.c')) > -system_ss.add(when: 'CONFIG_LASI_I82596', if_true: files('lasi_i82596.c')) > +system_ss.add(when: 'CONFIG_LASI_82596', if_true: files('lasi_i82596.c')) > system_ss.add(when: 'CONFIG_I82596_COMMON', if_true: files('i82596.c')) > system_ss.add(when: 'CONFIG_SUNHME', if_true: files('sunhme.c')) > system_ss.add(when: 'CONFIG_FTGMAC100', if_true: files('ftgmac100.c')) Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2144 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:34:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:34:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674271.1049108 (Exim 4.92) (envelope-from ) id 1rVUO9-0006Kg-Py; Thu, 01 Feb 2024 10:33:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674271.1049108; Thu, 01 Feb 2024 10: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 1rVUO9-0006KZ-MG; Thu, 01 Feb 2024 10:33:45 +0000 Received: by outflank-mailman (input) for mailman id 674271; Thu, 01 Feb 2024 10:33: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 1rVUO8-0006KQ-B6 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:33:44 +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 5f1cbb73-c0ed-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 11:33:43 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40e80046264so6792725e9.0 for ; Thu, 01 Feb 2024 02:33:43 -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 g10-20020a05600c4eca00b0040fbba734f3sm1395865wmq.34.2024.02.01.02.33.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 02:33: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: 5f1cbb73-c0ed-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706783622; x=1707388422; 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=D8J71cORIIJRoqYhXR8/qnQiyP/PfOcpk4LGA73fgB0=; b=ehCcxnN5SUNiax9nWYsD+sK7dGawQ90387sRVjM8UlSA7wS3hUAHsa/Mk+LZ3W/Gkx FjwtV7eD5grH7eB+UTyayD1jW+P9IZzWpYqTjCjNqcTGqaglXG5ePiQdhKX22mM6Y7pO DMSrpuNPo6xN5Y8kAembfTXKWNaCdtNDeL0Lw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706783622; x=1707388422; 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=D8J71cORIIJRoqYhXR8/qnQiyP/PfOcpk4LGA73fgB0=; b=Bk9gI8tO1ePfj0P8mmgwxFq/aQaGad6ZOlCkWaYRPoItMZXWuFAFxsQObk+TOEGzum FPxgHibMhWf00+Srm1y4gI4Jpm13ex5uMsf87ZPa+/py7BhB0r50Xe/8D5X/TkJbkz5k d5JVUD/VySBgvvoufxSKOU3e6uAne0l+qfcJKksjZnFMUg98JR/fOci07uXPfZe5HRxX BtJi3CZqjv81UsHDSPK72iGBlZdm6IHjFEwK6AvWhyEcZTramtyPURRTxU98Oyqy1R0l X3ZuYfaCnLUoSA0bRIEHPI/g47aMS9syi5pf2Q75Hoe2I/k7uCs879/08MTa9mqjcpKb l4mg== X-Gm-Message-State: AOJu0Yx2PdB7byHM4PH+jcZ7cvC2xKgzHNn8sYZr4WBYLTTrNs+KeJuL MHEYhS0b01GRN8o0IISH363FG0/lnPNES2+fAOPe1otkp07j6tcsicm4T4kYdOwir3/M9v856QN w X-Google-Smtp-Source: AGHT+IHFb00cp37ppIbJJKHh4MJRADrSYXz3jmxNOyaAIEpn5stWts3uRs9zYdfitFoGEmO37ivjlQ== X-Received: by 2002:a05:600c:3d88:b0:40f:b8e7:ad51 with SMTP id bi8-20020a05600c3d8800b0040fb8e7ad51mr1510749wmb.31.1706783622063; Thu, 01 Feb 2024 02:33:42 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUBY5YRDQ0F/TzC+6OmFx9c5nokmfEOljkdq0czD5PZFyC5kwbob7tsFyYLMm35OZxSGhC8oiE4dScslf5XPYuCsev3lyimueyppHDkKLIki6MDFxZ8paolBaKusCj9sHbFiKd0zoNYtZINe4w8cYmW27AW3i3pCB6OD7bqnLJj+xd/et6WxsfwnjQx+QjnIA== From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , George Dunlap , Jan Beulich , Stefano Stabellini , Wei Liu , Julien Grall Subject: [PATCH] xen/bitmap: Consistently use unsigned bits values Date: Thu, 1 Feb 2024 10:33:39 +0000 Message-Id: <20240201103339.549307-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Right now, most of the static inline helpers take an unsigned nbits quantity, and most of the library functions take a signed quanity. Because BITMAP_LAST_WORD_MASK() is expressed as a divide, the compiler is forced to emit two different paths to get the correct semantics for signed division. Swap all signed bit-counts to being unsigned bit-counts for the simple cases. This includes the return value of bitmap_weight(). Bloat-o-meter for a random x86 build reports: add/remove: 0/0 grow/shrink: 8/19 up/down: 167/-413 (-246) which all comes from compiler not emitting "dead" logic paths for negative bit counts. No functional change. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall Found when investigating negative-shift UBSAN, because each of the library functions ended up being instrumented. There is much more wanting cleaning up here, but we have to start somewhere. Some observations: * Various of the boolean-like return values have -1 for zero-length bitmaps. I can't spot any callers which care, so this seems like a waste. * bitmap_zero() and similar clear predate us switching to use __builtin_memset(), because there's no need for bitmap_switch(). * Should we consolidate 'bits' vs 'nbits'? * The internals of these helpers want converting too. Other helpers need more than just a parameter conversion. --- xen/common/bitmap.c | 24 +++++++++++----------- xen/include/xen/bitmap.h | 43 ++++++++++++++++++++-------------------- 2 files changed, 34 insertions(+), 33 deletions(-) diff --git a/xen/common/bitmap.c b/xen/common/bitmap.c index 7d4551f78283..c57b35f0042c 100644 --- a/xen/common/bitmap.c +++ b/xen/common/bitmap.c @@ -55,7 +55,7 @@ static void clamp_last_byte(uint8_t *bp, unsigned int nbits) bp[nbits/8] &= (1U << remainder) - 1; } -int __bitmap_empty(const unsigned long *bitmap, int bits) +int __bitmap_empty(const unsigned long *bitmap, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -70,7 +70,7 @@ int __bitmap_empty(const unsigned long *bitmap, int bits) } EXPORT_SYMBOL(__bitmap_empty); -int __bitmap_full(const unsigned long *bitmap, int bits) +int __bitmap_full(const unsigned long *bitmap, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -86,7 +86,7 @@ int __bitmap_full(const unsigned long *bitmap, int bits) EXPORT_SYMBOL(__bitmap_full); int __bitmap_equal(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -101,7 +101,7 @@ int __bitmap_equal(const unsigned long *bitmap1, } EXPORT_SYMBOL(__bitmap_equal); -void __bitmap_complement(unsigned long *dst, const unsigned long *src, int bits) +void __bitmap_complement(unsigned long *dst, const unsigned long *src, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -113,7 +113,7 @@ void __bitmap_complement(unsigned long *dst, const unsigned long *src, int bits) EXPORT_SYMBOL(__bitmap_complement); void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k; int nr = BITS_TO_LONGS(bits); @@ -124,7 +124,7 @@ void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_and); void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k; int nr = BITS_TO_LONGS(bits); @@ -135,7 +135,7 @@ void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_or); void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k; int nr = BITS_TO_LONGS(bits); @@ -146,7 +146,7 @@ void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_xor); void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k; int nr = BITS_TO_LONGS(bits); @@ -157,7 +157,7 @@ void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_andnot); int __bitmap_intersects(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -172,7 +172,7 @@ int __bitmap_intersects(const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_intersects); int __bitmap_subset(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits) + const unsigned long *bitmap2, unsigned int bits) { int k, lim = bits/BITS_PER_LONG; for (k = 0; k < lim; ++k) @@ -187,7 +187,7 @@ int __bitmap_subset(const unsigned long *bitmap1, EXPORT_SYMBOL(__bitmap_subset); #if BITS_PER_LONG == 32 -int __bitmap_weight(const unsigned long *bitmap, int bits) +unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits) { int k, w = 0, lim = bits/BITS_PER_LONG; @@ -200,7 +200,7 @@ int __bitmap_weight(const unsigned long *bitmap, int bits) return w; } #else -int __bitmap_weight(const unsigned long *bitmap, int bits) +unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits) { int k, w = 0, lim = bits/BITS_PER_LONG; diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h index 657390e32ebc..b9f980e91930 100644 --- a/xen/include/xen/bitmap.h +++ b/xen/include/xen/bitmap.h @@ -66,25 +66,25 @@ * lib/bitmap.c provides these functions: */ -extern int __bitmap_empty(const unsigned long *bitmap, int bits); -extern int __bitmap_full(const unsigned long *bitmap, int bits); -extern int __bitmap_equal(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern void __bitmap_complement(unsigned long *dst, const unsigned long *src, - int bits); -extern void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern int __bitmap_intersects(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern int __bitmap_subset(const unsigned long *bitmap1, - const unsigned long *bitmap2, int bits); -extern int __bitmap_weight(const unsigned long *bitmap, int bits); +int __bitmap_empty(const unsigned long *bitmap, unsigned int bits); +int __bitmap_full(const unsigned long *bitmap, unsigned int bits); +int __bitmap_equal(const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +void __bitmap_complement(unsigned long *dst, const unsigned long *src, + unsigned int bits); +void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +int __bitmap_intersects(const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +int __bitmap_subset(const unsigned long *bitmap1, + const unsigned long *bitmap2, unsigned int bits); +unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits); extern void __bitmap_set(unsigned long *map, unsigned int start, int len); extern void __bitmap_clear(unsigned long *map, unsigned int start, int len); @@ -117,7 +117,7 @@ static inline void bitmap_zero(unsigned long *dst, unsigned int nbits) memset(dst, 0, bitmap_bytes(nbits))); } -static inline void bitmap_fill(unsigned long *dst, int nbits) +static inline void bitmap_fill(unsigned long *dst, unsigned int nbits) { size_t nlongs = BITS_TO_LONGS(nbits); @@ -224,7 +224,8 @@ static inline int bitmap_full(const unsigned long *src, unsigned int nbits) return __bitmap_full(src, nbits)); } -static inline int bitmap_weight(const unsigned long *src, int nbits) +static inline unsigned int bitmap_weight(const unsigned long *src, + unsigned int nbits) { return __bitmap_weight(src, nbits); } -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:35:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:35:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674275.1049117 (Exim 4.92) (envelope-from ) id 1rVUPZ-0006sh-5t; Thu, 01 Feb 2024 10:35:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674275.1049117; Thu, 01 Feb 2024 10:35: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 1rVUPZ-0006sa-39; Thu, 01 Feb 2024 10:35:13 +0000 Received: by outflank-mailman (input) for mailman id 674275; Thu, 01 Feb 2024 10:35: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 1rVUPW-0006sM-U0 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:35:10 +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 92445fb3-c0ed-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 11:35:09 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33ae6dfa923so452542f8f.1 for ; Thu, 01 Feb 2024 02:35: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 r6-20020adfca86000000b0033aed7423e8sm10424665wrh.11.2024.02.01.02.35.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 02:35: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: 92445fb3-c0ed-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706783708; x=1707388508; 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=yCiKinlpzlts0E4HThCuxCG1NalXkAwCr46PyLENUPc=; b=M9LUOs617+AOXH3uMO0bt3UJqNwDW092MZ1CeIWqNSyBsrMqg8WnSkQsLJc0eIc2wc TXh5yxG8GFJwirJgCt9JPTRTlf4dIq9+XJF4Z8ppCfAGWox+IiCcemmh3yxd4B9WXBxM xOP3X7CGR24xD7gtp6dlTYvhddsHNpb7ahFoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706783708; x=1707388508; 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=yCiKinlpzlts0E4HThCuxCG1NalXkAwCr46PyLENUPc=; b=ENrgldqzaws79gRZqPLmGgwODhgWPAbdPv4TElQMxqrqorizD/DmITir1hsSpKHQHe WOATdRPWfBPvaQHEiM5NXw4zw6+iGKWs0c2LYaKPyXHzbOYux/AS1pCn0QIAkAar7tx9 Cv8La08uzvFblNcSU/8BQwFJKTK2dQpLwKH6z407Yiuvme+wiH3tOU3ox+V5t19RqG4L m7xYnvZdINnQxUrUahR5Zfood1S50dlZw1LpqN/vL4CBelrFAf+N/u594AET49PYKWBw BExAtyNwfkkCoaJwPftlgtsCipSYshiMAEBHquO8pvBEPqRnhCKyMl4+Qbz6oTcVBjq+ sCzw== X-Gm-Message-State: AOJu0YwCGOzc0mqlTiPFBoE8tpzEAZHuf8dvHmYRZYojt8iq2E6jmMJG QHGvhqFClBzljekKbV/qNS9zvXnryLJK5lUp3aOmOKp+DBsrWHYcdm7oU+3ivq5OKDBQO1OYhqp g X-Google-Smtp-Source: AGHT+IF3IYhsbx8io/sHFiJrAGGdpXKU7tkn0zeXJuTqKsE29NOH/Gha7ryNWAFLJlbJgM1L9l+h2A== X-Received: by 2002:a5d:4145:0:b0:33a:e9b5:b14d with SMTP id c5-20020a5d4145000000b0033ae9b5b14dmr2981336wrq.65.1706783708297; Thu, 01 Feb 2024 02:35:08 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVyhCfZlgnvrfayBS3hs4UKFkj9Aq4QmIunFjb/f/qZoIKI+kW0GSETBvLqi9tfVYRiop8+ZAnArt+922jtvVmDIp+b98rGgDSJdmJI1LxZLfx2Fbwsw7C8UqItb0WR7NU66PdqUKP8VVzsARoEdK6qmKv/JJSKlpM7+wCPyObsuVrNVLXqc63+Rf/ocEdVTQ== From: Andrew Cooper To: Xen-devel Cc: Andrew Cooper , George Dunlap , Jan Beulich , Stefano Stabellini , Wei Liu , Julien Grall Subject: [PATCH] xen/bitmap: Drop unused headers Date: Thu, 1 Feb 2024 10:35:06 +0000 Message-Id: <20240201103506.549662-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Nothing in bitmap.h uses lib.h, and there's no point including types.h when we need to include bitops.h anyway. Signed-off-by: Andrew Cooper --- CC: George Dunlap CC: Jan Beulich CC: Stefano Stabellini CC: Wei Liu CC: Julien Grall --- xen/include/xen/bitmap.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/xen/include/xen/bitmap.h b/xen/include/xen/bitmap.h index b9f980e91930..9f749e3913d8 100644 --- a/xen/include/xen/bitmap.h +++ b/xen/include/xen/bitmap.h @@ -3,8 +3,6 @@ #ifndef __ASSEMBLY__ -#include -#include #include /* -- 2.30.2 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:45:40 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:45:40 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674281.1049127 (Exim 4.92) (envelope-from ) id 1rVUZc-0000VG-4D; Thu, 01 Feb 2024 10:45:36 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674281.1049127; Thu, 01 Feb 2024 10:45: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 1rVUZc-0000V9-1S; Thu, 01 Feb 2024 10:45:36 +0000 Received: by outflank-mailman (input) for mailman id 674281; Thu, 01 Feb 2024 10:45: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 1rVUZb-0000V2-Ao for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:45:35 +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 06d3df5d-c0ef-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 11:45:34 +0100 (CET) Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-558f523c072so1060281a12.2 for ; Thu, 01 Feb 2024 02:45: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 dh8-20020a0564021d2800b0055f0b3ec5d8sm3675264edb.36.2024.02.01.02.45.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 02:45: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: 06d3df5d-c0ef-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706784333; x=1707389133; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=36zQ2znP4kvPGoaJBxKSgCjs1iecbtwJ0jpIQ8VM5sM=; b=Di/Rw1OdfHBFgX9FwXAd0M/cffyCS9Gp/mLeBo3gMDfKy0Dt+N0fnCVprCV9GWx9nz w+IAslP8tn4fOFqgR6DB5Hw3aQFWJMgGP0wTPk/XAiBGFB4DDDSRRsb4F3ZggNF0M3+S QSkqRyvyZ9gUD9ieVLa835Ikleug9zH4gKQCbjwrA2L78icaqWXUSo3dU38B0KR7nUST v3Tgmg4Dgbvt/gjnYMlUefthmCyLMGnd4f67xStn9zRL6XDTF+m3OBBzGQeSVDIhszu7 POmzDh2bEiWTL2N3N7WIoknJ1G0vkxlaxCe1wnypRcpL5SDwJuSlaaQ7R8Bf2+FhLsX+ CrmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706784333; x=1707389133; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=36zQ2znP4kvPGoaJBxKSgCjs1iecbtwJ0jpIQ8VM5sM=; b=YpCUPLc3ujlZU32ZJmiMy3iqhsImcdwQmILy2zxH9a8oYrqA/qczWyJrnKY1Wa0+Az TiZFBLpc2PpstaFmUxh4MDYrf5LMzpWcxD0PDuRfg+WGnRNszuesHt/mlrTcKXTTz2SA rHoWEuSq8aFB16wzWXSSwBmcXgVIKmc7bNVHcwejfcCHXxH6P17tO0BWbZexsUxgkswp VAoeJwTvqOU6q3Md9W7wamvmY+2HS6VUvq9wPsHv8qHAJX6X61tuEQuG2Te7UfdmciqD RXlUlabOiSIF+P7VGUv/kw2uyBcEptbx+L0nExNAt7xt09rOWRzH2B1ki0CEwDxV5BmA 5Y4Q== X-Gm-Message-State: AOJu0Yxbp8SI73KmoOEgAi4by0nlZdxSKbfWC0pdXUWAf52DibPDan8k Snrok3d3sVn0H5tCwEVgKTfHtKBT++2URq515nUNE49A5TBlVHLfyI1YA9f1pQ== X-Google-Smtp-Source: AGHT+IHoKcEQI4G5dKMR9mfNE5wCzl3xe9xM2sdmat0isSflfGWkENqPDprgtmfVkSpMmKczQoqYnA== X-Received: by 2002:a05:6402:3126:b0:55f:7b91:cbd5 with SMTP id dd6-20020a056402312600b0055f7b91cbd5mr3283824edb.8.1706784333612; Thu, 01 Feb 2024 02:45:33 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWnqi44md3/rfvumnOnsPaJCA87tDh4NdQ44RQilWZKSX4l1wjKYee6wY5TPWL3POn+igT3rDAnhBFIXKm2kiwdoy/g729lqytUkN1Ogd0HNOh7c/vgqzkioWC83osRUUYjrWLoBbo7MRERvMgMd6CT9uiDyYaR5K3p0ISmszv5XU63 Message-ID: <88b0e4bb-7f1c-4dc6-a22b-42c5dcd2ca46@suse.com> Date: Thu, 1 Feb 2024 11:45:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/bitmap: Consistently use unsigned bits values Content-Language: en-US To: Andrew Cooper Cc: George Dunlap , Stefano Stabellini , Wei Liu , Julien Grall , Xen-devel References: <20240201103339.549307-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: <20240201103339.549307-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.02.2024 11:33, Andrew Cooper wrote: > Right now, most of the static inline helpers take an unsigned nbits quantity, > and most of the library functions take a signed quanity. Because > BITMAP_LAST_WORD_MASK() is expressed as a divide, the compiler is forced to > emit two different paths to get the correct semantics for signed division. > > Swap all signed bit-counts to being unsigned bit-counts for the simple cases. > This includes the return value of bitmap_weight(). > > Bloat-o-meter for a random x86 build reports: > add/remove: 0/0 grow/shrink: 8/19 up/down: 167/-413 (-246) > > which all comes from compiler not emitting "dead" logic paths for negative bit > counts. > > No functional change. > > Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich albeit with a question at the bottom. > There is much more wanting cleaning up here, but we have to start somewhere. > Some observations: > > * Various of the boolean-like return values have -1 for zero-length bitmaps. > I can't spot any callers which care, so this seems like a waste. > * bitmap_zero() and similar clear predate us switching to use > __builtin_memset(), because there's no need for bitmap_switch(). > * Should we consolidate 'bits' vs 'nbits'? This looks desirable to me. > * The internals of these helpers want converting too. Other helpers need > more than just a parameter conversion. This may or may not relate to my question; it's not exactly clear what you mean here. > --- a/xen/include/xen/bitmap.h > +++ b/xen/include/xen/bitmap.h > @@ -66,25 +66,25 @@ > * lib/bitmap.c provides these functions: > */ > > -extern int __bitmap_empty(const unsigned long *bitmap, int bits); > -extern int __bitmap_full(const unsigned long *bitmap, int bits); > -extern int __bitmap_equal(const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern void __bitmap_complement(unsigned long *dst, const unsigned long *src, > - int bits); > -extern void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern int __bitmap_intersects(const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern int __bitmap_subset(const unsigned long *bitmap1, > - const unsigned long *bitmap2, int bits); > -extern int __bitmap_weight(const unsigned long *bitmap, int bits); > +int __bitmap_empty(const unsigned long *bitmap, unsigned int bits); > +int __bitmap_full(const unsigned long *bitmap, unsigned int bits); > +int __bitmap_equal(const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +void __bitmap_complement(unsigned long *dst, const unsigned long *src, > + unsigned int bits); > +void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +int __bitmap_intersects(const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +int __bitmap_subset(const unsigned long *bitmap1, > + const unsigned long *bitmap2, unsigned int bits); > +unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits); > extern void __bitmap_set(unsigned long *map, unsigned int start, int len); > extern void __bitmap_clear(unsigned long *map, unsigned int start, int len); What about these two, and the subsequent (in the .c file at least) bitmap_*_region()? That last remark above may mean you deliberately left them out for now (which is okay - as you say, this is merely a 1st step). Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:46:07 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:46:07 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674283.1049138 (Exim 4.92) (envelope-from ) id 1rVUa7-0000xl-D1; Thu, 01 Feb 2024 10:46:07 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674283.1049138; Thu, 01 Feb 2024 10: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 1rVUa7-0000xe-98; Thu, 01 Feb 2024 10:46:07 +0000 Received: by outflank-mailman (input) for mailman id 674283; Thu, 01 Feb 2024 10:46: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 1rVUa6-0000wJ-GW for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:46:06 +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 19a9aead-c0ef-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 11:46:05 +0100 (CET) Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5112cb7ae27so1400712e87.0 for ; Thu, 01 Feb 2024 02:46: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 dh8-20020a0564021d2800b0055f0b3ec5d8sm3675264edb.36.2024.02.01.02.46.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 02:46: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: 19a9aead-c0ef-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706784365; x=1707389165; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HdmZFcuuIPK1Q90rspQKvLqZJBvx+8Rnf5ur+I73X64=; b=U8ROuIUHlCd+99sdwiitG1gmKnx7AxbYdA0ahc97jH5zq2dzChb3TedZDAMMyyskj3 mMyxTAg+Pj4oBO4n1sztYqNqVpV2ISEPDaJFpHXX/WxJ4YHfFj419DZExd/gwZnBy7Qg Oz3T75gM8vWD/ocnyew3MCqQDVEnn4nvg26G/GgEYmWibLbPvd8v9UhO/1balcPyU4HR vWUVl4mqB+Ku0KYbbl8p6eCBtvQGVLg5akA9YSf+CZBabqDYimTvoR6YxxWMnrKy5Kgc kpqYbbym8Wc+JuK8UKz4iwzYlyOLMdbGHj5sn9w/7fpsUGHUS00D+iTlYWZ8/bAMp+a6 lZLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706784365; x=1707389165; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HdmZFcuuIPK1Q90rspQKvLqZJBvx+8Rnf5ur+I73X64=; b=tiYqlbXqvthpm+KCDMiLMSghpx4nDK6FQGlG0/KPoLqsJnh/68TdK6VIANT4PCYCTg 2wy4s4VCVihICI705cjfIxfCKz7F6scW7iR+AYox6vQq+HTMyAKPz0C2wynudjvpeHla uN8RvssRNlZSQXR9Ch5fmIt7E957kGP55xVHw+afKvHV3gzu//E29HM87j8zrw5QiiCZ yN4zNu0g5YgBKs+nUBuuRUiHRcr8nkgvFD0/zEEjVzACZPRZ+2+rCLoeeiMvR7vqIqkR gJVMHqIknS1dzjjE0KRsSE1meCVaH+xxL8GQgKdLmhUshzQkYivLfjOB9gERte2BAZ0d Laeg== X-Gm-Message-State: AOJu0Yz6jP5dPhc5EfRIyFr3jaet7GUv9VL6S8jY7aV4tmdDl4ZbZFP/ uoBSSUSIEeWeRf1Kysq/03lq6zjkvTlJyXVnB8jG3jY2lvdmctC6ZlCQMO0VSg== X-Google-Smtp-Source: AGHT+IEtw/eyfacwle68fAA8jyfPWhq2Wtd9UuM/AS6Yf6sX+JkhGtqEZMHo1ubXosn5shU/MUCK5Q== X-Received: by 2002:a05:651c:2105:b0:2d0:7590:7dd6 with SMTP id a5-20020a05651c210500b002d075907dd6mr1340506ljq.5.1706784365185; Thu, 01 Feb 2024 02:46:05 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVquoUlq88gZmNPZqxy2SO3va5yUl9GUEiWzOCfruj8wzBq+Gm1asGPTelwtOccYJRG6dsXHB02w2mZ//OTcYd2v0J89gAgJIMIBmrg9XW8IRKRdbytszfQ80E5Vb1mrP2X0/2Gv6wGsy2Wgk1aBobG6KCyio+jgciywaS0vWqZTRn4 Message-ID: <81820a24-03c1-4926-bd0c-5c21ed982271@suse.com> Date: Thu, 1 Feb 2024 11:46:04 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/bitmap: Drop unused headers Content-Language: en-US To: Andrew Cooper Cc: George Dunlap , Stefano Stabellini , Wei Liu , Julien Grall , Xen-devel References: <20240201103506.549662-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: <20240201103506.549662-1-andrew.cooper3@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.02.2024 11:35, Andrew Cooper wrote: > Nothing in bitmap.h uses lib.h, and there's no point including types.h when we > need to include bitops.h anyway. > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:51:42 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:51:42 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674289.1049148 (Exim 4.92) (envelope-from ) id 1rVUfO-0003Aj-VN; Thu, 01 Feb 2024 10:51:34 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674289.1049148; Thu, 01 Feb 2024 10:51: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 1rVUfO-0003Ac-Ry; Thu, 01 Feb 2024 10:51:34 +0000 Received: by outflank-mailman (input) for mailman id 674289; Thu, 01 Feb 2024 10: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 1rVUfN-00039n-Fr for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:51:33 +0000 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [2a00:1450:4864:20::643]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id dc50aee3-c0ef-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 11:51:32 +0100 (CET) Received: by mail-ej1-x643.google.com with SMTP id a640c23a62f3a-a36126ee41eso94269566b.2 for ; Thu, 01 Feb 2024 02:51: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: dc50aee3-c0ef-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706784692; x=1707389492; darn=lists.xenproject.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/e2n3brzjS7sgJpoVZMw+wyx5Jd+q7mbKNa90maiaTQ=; b=dhCn9V9PyHw/jMSSThJKcZazcGT0Ygrk9XRlz1ekQnVK/DqKL+ZEyhd1so3LFbKSdK 8f5vqBuvT6fjQvvR1TvxNKfB4AzVPWJMCZgxkBOq3w4Nq7Lkm5p846MNWjLdM0N8mG/P y++MTWL+J1lJgJ6umQGZKPHS3euwd6w76Bgms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706784692; x=1707389492; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/e2n3brzjS7sgJpoVZMw+wyx5Jd+q7mbKNa90maiaTQ=; b=qJobS1l2p+MR6g+GD1nl/X2UtCyEVEzi8JjZA1eX//MwHaQ4/cb4TXfNCNTvyc0mSS +DnTobC52jipNJyI4FFQi0VTDIoJbqTRaCY1S1azUhaVLxURfB8oemoB6dierJ2QteGQ +3FBLaEHqoR/3lbdBUU1AoBjM4gK4cvwthWF5qVD3Q4FnTRWWf5RttJjN+lECXMhL2/1 lQJuVe17It5uPBP/54+HLsf9ltxGjqHMQ/v/1vQ5ljP4A73Px5vAe+WTc0hWtEuzAllz 50eQ13CGc5gQertXwCRS8ycOyeXTJdPM1kmz1b/2YVVxcV5qQXZphJvF9Lra/uBoxyH6 fOkw== X-Gm-Message-State: AOJu0Yz7xDIprxD8PnECTrPPIoMQugcP+hURP+xsggOum85h5IsQJAGI sjPMV9n/ABUCO+9GtHEMKi63F7GYhcNKHQanVLQHYf459iIzlnQj0muKhsfL8OqIHOn/HT2XvY+ r6MT7F6EanHNxeDn75kt80cxXtQ50Ofbm0ruTJN84Ju2TsKkXfRIOoUrl X-Google-Smtp-Source: AGHT+IEXayaWwGkYdvNw1Kt8cebqMKuLrh2e2Ffv7xtSrxXGNYNcl4BoF9N5/TgmA9WxTDbpmM0GBh/Od+Ej/yB/fPI= X-Received: by 2002:a17:906:6857:b0:a35:5b6:1e0f with SMTP id a23-20020a170906685700b00a3505b61e0fmr3210597ejs.71.1706784691644; Thu, 01 Feb 2024 02:51:31 -0800 (PST) MIME-Version: 1.0 From: Kelly Choi Date: Thu, 1 Feb 2024 10:50:55 +0000 Message-ID: Subject: Upcoming Social Event - Location! To: xen-devel@lists.xenproject.org, xen-users@lists.xenproject.org, xen-announce@lists.xenproject.org Content-Type: multipart/alternative; boundary="00000000000040f1ec06104fc74e" --00000000000040f1ec06104fc74e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I'm pleased to announce the location of our next social event! Join and chat with the Xen community, there will also be free food and drinks. *Date:* Wednesday 21st February 2024 *Time:* 5:30pm - 9pm (you are welcome to stay later if you wish) *Location:* The Portland Arms 129 Chesterton Rd Cambridge www.theportlandarms.co.uk T: 01223 357268 *Getting to the venue (more information here ):* There are pay and display spaces (free after 5pm) on Milton Road to the East of us or opposite on Chesterton Road. The nearest bus stops are: Chesterton Road, opposite the pub outside Hing Hung restaurant, and on Milton Road, near Westbrook centre, Citi 1, 9, X9 and The Busway. Cambridge North rail station is 2.3 miles away and Cambridge Central station is 2.4 miles. *To anticipate the number of attendees, please email me indicating you wish to attend. * *If you have any food allergies, let me know ahead of time. * Many thanks, Kelly Choi Community Manager Xen Project ---------- Forwarded message --------- From: Kelly Choi Date: Thu, Nov 23, 2023 at 1:01=E2=80=AFPM Subject: The Xen Project=E2=80=99s 20th Anniversary - Upcoming Social Event= ! To: , = , *The Xen Project=E2=80=99s 20th Anniversary* *Let's get together for an informal social, likely to be pizza/drinks and getting involved with the community. I hope to run these in future locations to give everyone a chance to attend.* *Date placeholder: Wednesday 21st February 2024* *Location: Cambridge* *Details TBC - **If you're interested, please reply to me directly and I will add you to the list.* *Celebrating Two Decades of Innovation* It=E2=80=99s hard to believe that two decades have passed since the incepti= on of the Xen Project, a trailblazing force in the world of open-source virtualization. As we raise our glasses to commemorate this momentous occasion, it=E2=80=99s not just a celebration of time but a reflection on t= he incredible journey that has defined the Xen Project=E2=80=99s legacy. *A Legacy of Innovation* In the year 2003, the Xen Project emerged as a pioneering open-source hypervisor, laying the groundwork for some of the most influential cloud infrastructures that shape our digital landscape today. Over the past 20 years, the Xen Project has not only endured but has thrived, continuously evolving to meet the dynamic demands of the ever-changing tech landscape. *Driving Technological Frontiers* >From data center and server virtualization to cloud computing, desktop virtualization, and fortifying desktop security and hardware appliances, the Xen Project has been at the forefront of driving technological innovation. With 20 years of relentless development, it has become synonymous with reliability, scalability, and adaptability. *Venturing into New Horizons* As we celebrate this milestone, we also look forward to the exciting new territories that the Xen Project is venturing into. From embedded virtualization to even making strides in the automotive industry, the Xen Project continues to push boundaries and redefine what=E2=80=99s possible i= n the world of open-source virtualization. *The Annual Event: Xen Project Developer and Design Summit* At the heart of this remarkable journey is the Xen Project Developer and Design Summit, an annual gathering of the community=E2=80=99s brilliant min= ds and power users. More than just a conference, it=E2=80=99s a celebration of ide= a exchange, a showcase of the latest advancements, a platform for sharing invaluable experiences, and a forum for strategic planning and collaborative efforts. Be sure to look out for our upcoming event in 2024. *A Vibrant Community Defining the Future* Beyond the code and technological achievements, the Xen Project=E2=80=99s s= trength lies in its vibrant community. It=E2=80=99s a community that has come toget= her to celebrate successes, overcome challenges, and collectively shape the future of open-source virtualization technology. Even to this day, community contributions and reviews are still going! *Looking Ahead* As we commemorate 20 years of innovation, we also eagerly anticipate the next chapter in the Xen Project=E2=80=99s journey. With gratitude for the p= ast and excitement for the future, we extend our deepest thanks to everyone who has contributed to this incredible legacy. Here=E2=80=99s to 20 years of pushing boundaries, fostering collaboration, = and shaping the digital landscape. Happy anniversary, Xen Project! The best is yet to come and I can=E2=80=99t= wait to see what we all achieve. Many thanks, Kelly Choi Open Source Community Manager XenServer, Cloud Software Group --00000000000040f1ec06104fc74e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

I'm pleased to announ= ce the location of our next social event!
Join and chat with the = Xen community, there will also be free food and drinks.

Date: Wednesday 21st February 2024

Time: 5:30pm - 9pm (you are welcome to stay later if you wish)

Location:
The Portland Arms
129 Cheste= rton Rd Cambridge
www.theportlandarms.co.uk
T: 01223 357268

Getting to the venue (more information here):
There= are pay and display spaces (free after 5pm) on Milton Road to the East of = us or opposite on Chesterton Road. The nearest bus stops are: Chesterton Ro= ad, opposite the pub outside Hing Hung restaurant, and on Milton Road, near= Westbrook centre, Citi 1, 9, X9 and The Busway. Cambridge North rail stati= on is 2.3 miles away and Cambridge Central station is 2.4 miles.=C2=A0
To anticipate the number of attendees, please email = me=C2=A0indicating you wish to attend.=C2=A0
If you have a= ny food allergies, let me know ahead of time.=C2=A0

Many thanks,
Kelly Choi
=
Community Manager
Xen Project=C2=A0


---------- Forwarded message ---------
From: Kelly Choi &= lt;kelly.choi@clo= ud.com>
Date: Thu, Nov 23, 2023 at 1:01=E2=80=AFPM
Subj= ect: The Xen Project=E2=80=99s 20th Anniversary - Upcoming Social Event! To: <advisory-board@lists.xenproject.org>, <xen-devel@lists.xenproj= ect.org>, <xen-users@lists.xenproject.org>


The Xen Project=E2=80=99s 20th Anniversary

Let's get=C2=A0together for an informal social, li= kely to be pizza/drinks and getting involved with the community. I hope to = run these in future locations to give everyone a chance to attend.

Date placeholder: Wednesday 21st February= 2024
Location: Cambridge
D= etails TBC -=C2=A0If you're inter= ested, please reply to me directly and I will add you to the list.

Celebrating Two Decades of Innovation

It=E2=80=99s hard to believe that two= decades have passed since the inception of the Xen Project, a trailblazing= force in the world of open-source virtualization. As we raise our glasses = to commemorate this momentous occasion, it=E2=80=99s not just a celebration= of time but a reflection on the incredible journey that has defined the Xe= n Project=E2=80=99s legacy.

A Legacy of Innovation

In = the year 2003, the Xen Project emerged as a pioneering open-source hypervis= or, laying the groundwork for some of the most influential cloud infrastruc= tures that shape our digital landscape today. Over the past 20 years, the X= en Project has not only endured but has thrived, continuously evolving to m= eet the dynamic demands of the ever-changing tech landscape.

Driv= ing Technological Frontiers

From data center and server virtuali= zation to cloud computing, desktop virtualization, and fortifying desktop s= ecurity and hardware appliances, the Xen Project has been at the forefront = of driving technological innovation. With 20 years of relentless developmen= t, it has become synonymous with reliability, scalability, and adaptability= .

Venturing into New Horizons

As we celebrate this mil= estone, we also look forward to the exciting new territories that the Xen P= roject is venturing into. From embedded virtualization to even making strid= es in the automotive industry, the Xen Project continues to push boundaries= and redefine what=E2=80=99s possible in the world of open-source virtualiz= ation.

The Annual Event: Xen Project Developer and Design Summit<= /b>

At the heart of this remarkable journey is the Xen Project Devel= oper and Design Summit, an annual gathering of the community=E2=80=99s bril= liant minds and power users. More than just a conference, it=E2=80=99s a ce= lebration of idea exchange, a showcase of the latest advancements, a platfo= rm for sharing invaluable experiences, and a forum for strategic planning a= nd collaborative efforts. Be sure to look out for our upcoming event in 202= 4.

A Vibrant Community Defining the Future

Beyond the = code and technological achievements, the Xen Project=E2=80=99s strength lie= s in its vibrant community. It=E2=80=99s a community that has come together= to celebrate successes, overcome challenges, and collectively shape the fu= ture of open-source virtualization technology. Even to this day, community = contributions and reviews are still going!

Looking Ahead
<= br>As we commemorate 20 years of innovation, we also eagerly anticipate the= next chapter in the Xen Project=E2=80=99s journey. With gratitude for the = past and excitement for the future, we extend our deepest thanks to everyon= e who has contributed to this incredible legacy.

Here=E2=80=99s to 2= 0 years of pushing boundaries, fostering collaboration, and shaping the dig= ital landscape.

Happy anniversary, Xen Project! The best is yet to c= ome and I can=E2=80=99t wait to see what we all achieve.

=
Many thanks,
Kelly Choi
=

Open Source Commu= nity Manager
XenServer, Cloud So= ftware Group
--00000000000040f1ec06104fc74e-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:54:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:54:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674322.1049187 (Exim 4.92) (envelope-from ) id 1rVUhg-0005D0-1l; Thu, 01 Feb 2024 10:53:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674322.1049187; Thu, 01 Feb 2024 10: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 1rVUhf-0005Ct-VQ; Thu, 01 Feb 2024 10:53:55 +0000 Received: by outflank-mailman (input) for mailman id 674322; Thu, 01 Feb 2024 10: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 1rVUhe-0005Cb-OC for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:53:54 +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 2ff1208d-c0f0-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 11:53:52 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-33ae4eb360aso460812f8f.0 for ; Thu, 01 Feb 2024 02:53:52 -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 cx18-20020a056000093200b0033935779a23sm15819798wrb.89.2024.02.01.02.53.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 02:53: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: 2ff1208d-c0f0-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706784832; x=1707389632; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt: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/7t2W/nuc1bPI8HTUKEuA5/guWmVVdGl+fvEX/9WfI=; b=F7AfHFIYSaesCkMjbBcDUbnQQup/J29SqDcBMBr9yriP/QeKJpattuGKiryETd36Gc g6i4Cqqidn9nOxq1HtG6ZM2uqYdPf87pIrTR4xAqRbpmxn1dFe7vvGsAMIOzntrfzWxr mBBiywqyCes1iCsaLa8kcpRcGhkJd8iLTSWf0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706784832; x=1707389632; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to: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/7t2W/nuc1bPI8HTUKEuA5/guWmVVdGl+fvEX/9WfI=; b=wHj6zGq7EK00exHYr2GT+wDmgVCZmPvFmu9tMOQJfX2auYacvlyCAebt5qL9z1UUH8 423cFZnjpE4BatbCrF1+4mLW0nUTJbDQWpiAOki1hooYIx9yj83YGf//taLd7uhTKJg0 9A6Ci06qhwDguqDNGewC2DgY4JqeZ0aVIFIc0xaD3fsyC4sFclwOkhWXBjvl7UwaryZl 2HKFPhyk5SirCQRpXOtfr2smSusy0LMZlB/4mQhHfcxNCoIW8N5QVfP9bZvjuSoxP/za KORR3dHF3/Q12lh0SEaMwCcUjaLdeSDiP4VMwfI5hevL3+Xz53UaZLFmLDsoaCYBCvj6 MQyQ== X-Gm-Message-State: AOJu0Yyq3liQVDqpY1kgANt4K3vTaaXyAVBZ2Vgx67NG+UAHGjd7lbF6 uCBcWsVRJKe51AcGZ3ntBWHwFJsoG4vKxaomNJqUu/yrUX9aXq4+N+DzD8/RAvQ= X-Google-Smtp-Source: AGHT+IG0qUNhArOIAClSjVvblXAHmw0o/Fns4eTQZQNNsvsb4fLEMsEMpFPi3EshofloyGkaBfMWmA== X-Received: by 2002:a5d:4710:0:b0:33a:ee33:ae9b with SMTP id y16-20020a5d4710000000b0033aee33ae9bmr3841202wrq.32.1706784832032; Thu, 01 Feb 2024 02:53:52 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUrfGCGQDe/ZzFIomh2xIw9PFGV+W3jUNe4mE3wWF3gp34F77j6V9/1w/zZLFQg3N7a/UtKhcHRCIyk2tA97VsLmjZcvDpm62jCwAvVo712a6Lykv5hQKKVA9SECUD8gnKFvH5RYnyF8VNRUIhQbBMvl9ANtxTcg9k4HZtE9/FXC+pf Message-ID: <7b6e70a9-f19b-4487-ae92-6480ff0edfd5@citrix.com> Date: Thu, 1 Feb 2024 10:53:51 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/bitmap: Consistently use unsigned bits values Content-Language: en-GB To: Jan Beulich Cc: George Dunlap , Stefano Stabellini , Wei Liu , Julien Grall , Xen-devel References: <20240201103339.549307-1-andrew.cooper3@citrix.com> <88b0e4bb-7f1c-4dc6-a22b-42c5dcd2ca46@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: <88b0e4bb-7f1c-4dc6-a22b-42c5dcd2ca46@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 01/02/2024 10:45 am, Jan Beulich wrote: > On 01.02.2024 11:33, Andrew Cooper wrote: >> Right now, most of the static inline helpers take an unsigned nbits quantity, >> and most of the library functions take a signed quanity. Because >> BITMAP_LAST_WORD_MASK() is expressed as a divide, the compiler is forced to >> emit two different paths to get the correct semantics for signed division. >> >> Swap all signed bit-counts to being unsigned bit-counts for the simple cases. >> This includes the return value of bitmap_weight(). >> >> Bloat-o-meter for a random x86 build reports: >> add/remove: 0/0 grow/shrink: 8/19 up/down: 167/-413 (-246) >> >> which all comes from compiler not emitting "dead" logic paths for negative bit >> counts. >> >> No functional change. >> >> Signed-off-by: Andrew Cooper > Reviewed-by: Jan Beulich Thanks. > albeit with a question at the bottom. > >> There is much more wanting cleaning up here, but we have to start somewhere. >> Some observations: >> >> * Various of the boolean-like return values have -1 for zero-length bitmaps. >> I can't spot any callers which care, so this seems like a waste. >> * bitmap_zero() and similar clear predate us switching to use >> __builtin_memset(), because there's no need for bitmap_switch(). >> * Should we consolidate 'bits' vs 'nbits'? > This looks desirable to me. > >> * The internals of these helpers want converting too. Other helpers need >> more than just a parameter conversion. > This may or may not relate to my question; it's not exactly clear what you > mean here. > >> --- a/xen/include/xen/bitmap.h >> +++ b/xen/include/xen/bitmap.h >> @@ -66,25 +66,25 @@ >> * lib/bitmap.c provides these functions: >> */ >> >> -extern int __bitmap_empty(const unsigned long *bitmap, int bits); >> -extern int __bitmap_full(const unsigned long *bitmap, int bits); >> -extern int __bitmap_equal(const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern void __bitmap_complement(unsigned long *dst, const unsigned long *src, >> - int bits); >> -extern void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern int __bitmap_intersects(const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern int __bitmap_subset(const unsigned long *bitmap1, >> - const unsigned long *bitmap2, int bits); >> -extern int __bitmap_weight(const unsigned long *bitmap, int bits); >> +int __bitmap_empty(const unsigned long *bitmap, unsigned int bits); >> +int __bitmap_full(const unsigned long *bitmap, unsigned int bits); >> +int __bitmap_equal(const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +void __bitmap_complement(unsigned long *dst, const unsigned long *src, >> + unsigned int bits); >> +void __bitmap_and(unsigned long *dst, const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +void __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +int __bitmap_intersects(const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +int __bitmap_subset(const unsigned long *bitmap1, >> + const unsigned long *bitmap2, unsigned int bits); >> +unsigned int __bitmap_weight(const unsigned long *bitmap, unsigned int bits); >> extern void __bitmap_set(unsigned long *map, unsigned int start, int len); >> extern void __bitmap_clear(unsigned long *map, unsigned int start, int len); > What about these two, and the subsequent (in the .c file at least) > bitmap_*_region()? That last remark above may mean you deliberately > left them out for now (which is okay - as you say, this is merely a > 1st step). They want map->bitmap and int len -> unsigned int bits for consistency, which is more than just a typechange. I also wasn't totally certain of the correctness of the internal logic.  I don't have time to investigate further in the immediate future, so left it unchanged out of caution. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Feb 01 10:57:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 10:57:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674335.1049198 (Exim 4.92) (envelope-from ) id 1rVUkp-00062W-GQ; Thu, 01 Feb 2024 10:57:11 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674335.1049198; Thu, 01 Feb 2024 10: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 1rVUkp-00062P-Bp; Thu, 01 Feb 2024 10:57:11 +0000 Received: by outflank-mailman (input) for mailman id 674335; Thu, 01 Feb 2024 10: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 1rVUko-00062J-9f for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 10:57:10 +0000 Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [2a00:1450:4864:20::42c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id a4759ebf-c0f0-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 11:57:08 +0100 (CET) Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-33b1117bbe4so468501f8f.0 for ; Thu, 01 Feb 2024 02: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 h15-20020a05600016cf00b0033aedfc5581sm10506517wrf.32.2024.02.01.02.57.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 02: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: a4759ebf-c0f0-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706785027; x=1707389827; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wHfXA9CWPeygkYwIqkcdbd05IHnuqGa1RECkAr53WVo=; b=asFPrVO7b0QjErlBxkbHr6Y6E3/6ovF/W2NHKSt31VKjFD3aiw4LlUxdJsLE4s5ZVH 4cNAuRwcnSUoQfrZZS6NLDgiJlgYiuQVuasNKQBgGW3xHhRsPu4PgHO3R+T1YmoJItFs EXyKYVm9jEG5lXYHW+9N/bv1BAiXtOCqjg3le0qMQBfon2NLZ+rKkEsYcR7yznOgn+yD EIrZSBVikXvYcUnK3a/JUjrMX6j1qG+rWPxHWQ9U5GI8x7fGwtj1WqBMNx6qZmK9ya4I BzuzRs1r1gmEOhOHVR9X0ZxjUdwE7nQRXLcm7DnLXt/NsdENKLltIGIKu90nsgP//60P Ar6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706785027; x=1707389827; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wHfXA9CWPeygkYwIqkcdbd05IHnuqGa1RECkAr53WVo=; b=UFdpmo3QfsiBcFpYTUo6o2eyVIyiQinXGfE4u5acHW3us9PzgQX0gnb4cbs811+GzT aSgwBc00ViGmc6LZmUfsu6QAhZEieQM7DNfCBtWwbnK3ym3QRbdT96zT7MrM53hNBFn6 FHOuuRUcXlyoF5S8caJZaYbm+hdV0o4iach6VZAJDs2YpmvO0LCv2w1gYVd2Rt7ElrA/ qgWfwqHpTXgLESx/AY7J2eDiYBDDEDQVF3+DdhvEcud4m7rOwKxvxYL+51RGO2IMLc17 iQDHWhqefSBI5bxz99+rPKzD3GlyQcDxEIll5C0FwLYhBKOkuYjJaXoaJklgkTxgx6ta X3Gw== X-Gm-Message-State: AOJu0Yys7yFUsV6a9VKF9iZY5XJmxuQsDEfWsRSqcG+1NwApytmZ0k+I zVnLv9F03Budn4+PtiA2fQ5qmWfkqA3g3xUiOveBKNiI0V0QzH1z+0KCoauFVw== X-Google-Smtp-Source: AGHT+IFanJa09jb1jj3FfMdUHrewWqzuq4tYduICl2RdJ1jrJaEwQgKLGHt9+Y7Xjaxk4/vTfBTB4Q== X-Received: by 2002:a05:6000:18ad:b0:33a:f3dd:97e9 with SMTP id b13-20020a05600018ad00b0033af3dd97e9mr3796510wri.40.1706785027455; Thu, 01 Feb 2024 02:57:07 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUuDNLxcpFtX35VuilYbBCDQl1DrMo5MLB0ykN0JZyRDKlwIC7hZBaFo2S9UEEDblvWSIQ05zpvYiHc9Rz4I1k5VEbIp9+nuYOjhy/KFsM= Message-ID: <5cda514b-4b6f-4259-9dbc-bb1462eec13e@suse.com> Date: Thu, 1 Feb 2024 11:57:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Issue iommu unrecognized on amd computer Content-Language: en-US To: oxjo@proton.me Cc: "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 01.02.2024 09:16, oxjo@proton.me wrote: > Following our interaction on matrix, I send you the boot log `xl dmesg` output of my computer, booting with `iommu=debug` options on linux 6.6.13-200.fc39. There's no "iommu=debug" anywhere in sight: (XEN) Command line: placeholder no-real-mode edd=off Did you mistakenly put it on the Linux command line? Nevertheless there are relevant messages already without the extra verbosity (and without you using a debug build of Xen, which would be preferable): (XEN) AMD-Vi: Warning: IVMD: [c9f1c000,c9f42000) is not (entirely) in reserved memory (XEN) AMD-Vi: Error: IVMD: page at c9f1c000 can't be converted (XEN) AMD-Vi: Error initialization Quoting the respective entry from the memory map: (XEN) [00000000c8f58000, 00000000c9f57fff] (ACPI NVS) Both Roger and I look to agree that this condition we have if ( !(type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | RAM_TYPE_UNUSABLE)) ) is inverted in some way. We merely need to agree in which way it wants adjusting. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 11:50:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 11:50:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674356.1049206 (Exim 4.92) (envelope-from ) id 1rVVaD-0002F3-Bw; Thu, 01 Feb 2024 11:50:17 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674356.1049206; Thu, 01 Feb 2024 11: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 1rVVaD-0002Ew-9F; Thu, 01 Feb 2024 11:50:17 +0000 Received: by outflank-mailman (input) for mailman id 674356; Thu, 01 Feb 2024 11:50: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 1rVVaB-0002DW-Pu for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 11:50:15 +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 0f061d62-c0f8-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 12:50:13 +0100 (CET) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a26ed1e05c7so116894166b.2 for ; Thu, 01 Feb 2024 03:50:13 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id fj17-20020a1709069c9100b00a36d0dae491sm275054ejc.202.2024.02.01.03.50.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 03:50: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: 0f061d62-c0f8-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706788213; x=1707393013; 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=/b2nCxVuhiNKnJIcxnoWW7CsS5U/pLdZUbH4D9pjupQ=; b=RJT6t6omnWCpwhysmMmIuy8b22WELM6osuIkyrBpCYL7NdW9KLJpq4cCjqcodKXn21 Bd6eUMdpi8LH/6aFyncqyO4sFGEtV6JHOQ+qcQodJB0TGAZV8RzKqHuRaCYpdTD85uVV udEiBiAjJgBVufw5wztPfzFzf7rISVjayjbWs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706788213; x=1707393013; 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=/b2nCxVuhiNKnJIcxnoWW7CsS5U/pLdZUbH4D9pjupQ=; b=dKtxvCVZH11mCgB16oHEKy6tIO9wp6wSjDhH6DIPprky2yygYX2NJL4jp7Ok8SbXox eJ6zLNKtnfQbP0iED0CKpFvjs72yXxIXQY4FOLAWw2rKqp3h03+0Dyqrff90xKk3e17Z GiPFVQ2EbQbATuCJoTYhiyXmkCuNYa5eLbHJPOBFDtgftvpQ5hHqRrtchs0jMVi4F7rO GS+0eRiOlCMeYIYOegBazFPnlFRGdObuj9NU7XJW9S7nGNTi667sOpDhhzroFO0r+28D 7NoyWstFP4Tdnt5D92i06nZ8EBF/c4USeGGppn2v8tdDub+ARPH4F1t6wj3LOcreHmHq IIKQ== X-Gm-Message-State: AOJu0Ywz3YBzZpxkpvzM/cxSN+TM2xemw8X1bMSvRxKwgqgrxWP6vRoD DjZIINNHw+/1I+BNxMuVl8uCjhY+0A9qOQhQJWOMRxYkZmLwUO6zNdD5QMPj9PQ= X-Google-Smtp-Source: AGHT+IEx/y0d9DNtQS9M0vQ0aGFGc9W/x/9Cnr/JO2o61EjFrMzGGqzlCsG5Kr9w497A1VY4CBEMUQ== X-Received: by 2002:a17:906:260b:b0:a36:34b6:9ca4 with SMTP id h11-20020a170906260b00b00a3634b69ca4mr1758930ejc.64.1706788212751; Thu, 01 Feb 2024 03:50:12 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXVZ+Yq4REdfLsj1fV3tQfEcqzAeR0Cu2JkvNGBlJ3yO5Hj1WF4Uu2XxMDuv/vspIDPCtaTc8BVvGNYDbVsCBruAPuTk/RtKBxNEBTJOQ5Lak4jeIAindJhSH2iboYHv4ts8I2NaZX+2+xbmVEXG4Sv+JIDlAa2yqPyABc4diL8I6rEqw== Date: Thu, 1 Feb 2024 12:50:11 +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 v4 3/8] VMX: tertiary execution control infrastructure Message-ID: References: <9dd23064-c79e-4a50-9c71-c0e73b189944@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Thu, Jan 11, 2024 at 10:00:10AM +0100, Jan Beulich wrote: > This is a prereq to enabling the MSRLIST feature. > > Note that the PROCBASED_CTLS3 MSR is different from other VMX feature > reporting MSRs, in that all 64 bits report allowed 1-settings. > > vVMX code is left alone, though, for the time being. > > Signed-off-by: Jan Beulich > --- > v2: New. > > --- a/xen/arch/x86/hvm/vmx/vmcs.c > +++ b/xen/arch/x86/hvm/vmx/vmcs.c > @@ -164,6 +164,7 @@ static int cf_check parse_ept_param_runt > u32 vmx_pin_based_exec_control __read_mostly; > u32 vmx_cpu_based_exec_control __read_mostly; > u32 vmx_secondary_exec_control __read_mostly; > +uint64_t vmx_tertiary_exec_control __read_mostly; > u32 vmx_vmexit_control __read_mostly; > u32 vmx_vmentry_control __read_mostly; > u64 vmx_ept_vpid_cap __read_mostly; > @@ -228,10 +229,32 @@ static u32 adjust_vmx_controls( > return ctl; > } > > -static bool cap_check(const char *name, u32 expected, u32 saw) > +static uint64_t adjust_vmx_controls2( > + const char *name, uint64_t ctl_min, uint64_t ctl_opt, unsigned int msr, > + bool *mismatch) > +{ > + uint64_t vmx_msr, ctl = ctl_min | ctl_opt; > + > + rdmsrl(msr, vmx_msr); > + > + ctl &= vmx_msr; /* bit == 0 ==> must be zero */ > + > + /* Ensure minimum (required) set of control bits are supported. */ > + if ( ctl_min & ~ctl ) > + { > + *mismatch = true; > + printk("VMX: CPU%u has insufficient %s (%#lx; requires %#lx)\n", > + smp_processor_id(), name, ctl, ctl_min); > + } > + > + return ctl; > +} > + > +static bool cap_check( > + const char *name, unsigned long expected, unsigned long saw) > { > if ( saw != expected ) > - printk("VMX %s: saw %#x expected %#x\n", name, saw, expected); > + printk("VMX %s: saw %#lx expected %#lx\n", name, saw, expected); > return saw != expected; > } > > @@ -241,6 +264,7 @@ static int vmx_init_vmcs_config(bool bsp > u32 _vmx_pin_based_exec_control; > u32 _vmx_cpu_based_exec_control; > u32 _vmx_secondary_exec_control = 0; > + uint64_t _vmx_tertiary_exec_control = 0; > u64 _vmx_ept_vpid_cap = 0; > u64 _vmx_misc_cap = 0; > u32 _vmx_vmexit_control; > @@ -274,7 +298,8 @@ static int vmx_init_vmcs_config(bool bsp > opt = (CPU_BASED_ACTIVATE_MSR_BITMAP | > CPU_BASED_TPR_SHADOW | > CPU_BASED_MONITOR_TRAP_FLAG | > - CPU_BASED_ACTIVATE_SECONDARY_CONTROLS); > + CPU_BASED_ACTIVATE_SECONDARY_CONTROLS | > + CPU_BASED_ACTIVATE_TERTIARY_CONTROLS); > _vmx_cpu_based_exec_control = adjust_vmx_controls( > "CPU-Based Exec Control", min, opt, > MSR_IA32_VMX_PROCBASED_CTLS, &mismatch); > @@ -338,6 +363,15 @@ static int vmx_init_vmcs_config(bool bsp > MSR_IA32_VMX_PROCBASED_CTLS2, &mismatch); > } > > + if ( _vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS ) > + { > + uint64_t opt = 0; > + > + _vmx_tertiary_exec_control = adjust_vmx_controls2( > + "Tertiary Exec Control", 0, opt, > + MSR_IA32_VMX_PROCBASED_CTLS3, &mismatch); > + } > + > /* The IA32_VMX_EPT_VPID_CAP MSR exists only when EPT or VPID available */ > if ( _vmx_secondary_exec_control & (SECONDARY_EXEC_ENABLE_EPT | > SECONDARY_EXEC_ENABLE_VPID) ) > @@ -468,6 +502,7 @@ static int vmx_init_vmcs_config(bool bsp > vmx_pin_based_exec_control = _vmx_pin_based_exec_control; > vmx_cpu_based_exec_control = _vmx_cpu_based_exec_control; > vmx_secondary_exec_control = _vmx_secondary_exec_control; > + vmx_tertiary_exec_control = _vmx_tertiary_exec_control; > vmx_ept_vpid_cap = _vmx_ept_vpid_cap; > vmx_vmexit_control = _vmx_vmexit_control; > vmx_vmentry_control = _vmx_vmentry_control; > @@ -503,6 +538,9 @@ static int vmx_init_vmcs_config(bool bsp > "Secondary Exec Control", > vmx_secondary_exec_control, _vmx_secondary_exec_control); > mismatch |= cap_check( > + "Tertiary Exec Control", > + vmx_tertiary_exec_control, _vmx_tertiary_exec_control); I know it's done to match the surrounding style, but couldn't you move the name parameter one line up, and then limit the call to two lines? (I don't think it will compromise readability). > + mismatch |= cap_check( > "VMExit Control", > vmx_vmexit_control, _vmx_vmexit_control); > mismatch |= cap_check( > @@ -1080,6 +1118,7 @@ static int construct_vmcs(struct vcpu *v > v->arch.hvm.vmx.exec_control |= CPU_BASED_RDTSC_EXITING; > > v->arch.hvm.vmx.secondary_exec_control = vmx_secondary_exec_control; > + v->arch.hvm.vmx.tertiary_exec_control = vmx_tertiary_exec_control; > > /* > * Disable features which we don't want active by default: > @@ -1134,6 +1173,10 @@ static int construct_vmcs(struct vcpu *v > __vmwrite(SECONDARY_VM_EXEC_CONTROL, > v->arch.hvm.vmx.secondary_exec_control); > > + if ( cpu_has_vmx_tertiary_exec_control ) > + __vmwrite(TERTIARY_VM_EXEC_CONTROL, > + v->arch.hvm.vmx.tertiary_exec_control); > + > /* MSR access bitmap. */ > if ( cpu_has_vmx_msr_bitmap ) > { > @@ -2068,10 +2111,12 @@ void vmcs_dump_vcpu(struct vcpu *v) > vmr(HOST_PERF_GLOBAL_CTRL)); > > printk("*** Control State ***\n"); > - printk("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n", > + printk("PinBased=%08x CPUBased=%08x\n", > vmr32(PIN_BASED_VM_EXEC_CONTROL), > - vmr32(CPU_BASED_VM_EXEC_CONTROL), > - vmr32(SECONDARY_VM_EXEC_CONTROL)); > + vmr32(CPU_BASED_VM_EXEC_CONTROL)); > + printk("SecondaryExec=%08x TertiaryExec=%08lx\n", For consistency, shouldn't TertiaryExec use 016 instead of 08 (as it's a 64bit filed). > + vmr32(SECONDARY_VM_EXEC_CONTROL), > + vmr(TERTIARY_VM_EXEC_CONTROL)); > printk("EntryControls=%08x ExitControls=%08x\n", vmentry_ctl, vmexit_ctl); > printk("ExceptionBitmap=%08x PFECmask=%08x PFECmatch=%08x\n", > vmr32(EXCEPTION_BITMAP), > --- a/xen/arch/x86/include/asm/hvm/vmx/vmcs.h > +++ b/xen/arch/x86/include/asm/hvm/vmx/vmcs.h > @@ -114,6 +114,7 @@ struct vmx_vcpu { > /* Cache of cpu execution control. */ > u32 exec_control; > u32 secondary_exec_control; > + uint64_t tertiary_exec_control; > u32 exception_bitmap; > > uint64_t shadow_gs; > @@ -196,6 +197,7 @@ void vmx_vmcs_reload(struct vcpu *v); > #define CPU_BASED_RDTSC_EXITING 0x00001000U > #define CPU_BASED_CR3_LOAD_EXITING 0x00008000U > #define CPU_BASED_CR3_STORE_EXITING 0x00010000U > +#define CPU_BASED_ACTIVATE_TERTIARY_CONTROLS 0x00020000U > #define CPU_BASED_CR8_LOAD_EXITING 0x00080000U > #define CPU_BASED_CR8_STORE_EXITING 0x00100000U > #define CPU_BASED_TPR_SHADOW 0x00200000U > @@ -260,6 +262,13 @@ extern u32 vmx_vmentry_control; > #define SECONDARY_EXEC_NOTIFY_VM_EXITING 0x80000000U > extern u32 vmx_secondary_exec_control; > > +#define TERTIARY_EXEC_LOADIWKEY_EXITING BIT(0, UL) > +#define TERTIARY_EXEC_ENABLE_HLAT BIT(1, UL) > +#define TERTIARY_EXEC_EPT_PAGING_WRITE BIT(2, UL) > +#define TERTIARY_EXEC_GUEST_PAGING_VERIFY BIT(3, UL) > +#define TERTIARY_EXEC_IPI_VIRT BIT(4, UL) While at it, my copy of the SDM also has: #define TERTIARY_EXEC_VIRT_SPEC_CTRL BIT(7, UL) > +extern uint64_t vmx_tertiary_exec_control; > + > #define VMX_EPT_EXEC_ONLY_SUPPORTED 0x00000001 > #define VMX_EPT_WALK_LENGTH_4_SUPPORTED 0x00000040 > #define VMX_EPT_MEMORY_TYPE_UC 0x00000100 > @@ -295,6 +304,8 @@ extern u64 vmx_ept_vpid_cap; > (vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_MSR_BITMAP) > #define cpu_has_vmx_secondary_exec_control \ > (vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) > +#define cpu_has_vmx_tertiary_exec_control \ > + (vmx_cpu_based_exec_control & CPU_BASED_ACTIVATE_TERTIARY_CONTROLS) > #define cpu_has_vmx_ept \ > (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT) > #define cpu_has_vmx_dt_exiting \ > @@ -422,6 +433,7 @@ enum vmcs_field { > VIRT_EXCEPTION_INFO = 0x0000202a, > XSS_EXIT_BITMAP = 0x0000202c, > TSC_MULTIPLIER = 0x00002032, > + TERTIARY_VM_EXEC_CONTROL = 0x00002034, > GUEST_PHYSICAL_ADDRESS = 0x00002400, > VMCS_LINK_POINTER = 0x00002800, > GUEST_IA32_DEBUGCTL = 0x00002802, > --- a/xen/arch/x86/include/asm/msr-index.h > +++ b/xen/arch/x86/include/asm/msr-index.h > @@ -347,6 +347,7 @@ > #define MSR_IA32_VMX_TRUE_EXIT_CTLS 0x48f > #define MSR_IA32_VMX_TRUE_ENTRY_CTLS 0x490 > #define MSR_IA32_VMX_VMFUNC 0x491 > +#define MSR_IA32_VMX_PROCBASED_CTLS3 0x492 Shouldn't this be added above the "Legacy MSR constants in need of cleanup. No new MSRs below this comment." line? > > /* K7/K8 MSRs. Not complete. See the architecture manual for a more > complete list. */ > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -760,6 +760,12 @@ void vmx_update_secondary_exec_control(s > v->arch.hvm.vmx.secondary_exec_control); > } > > +void vmx_update_tertiary_exec_control(struct vcpu *v) const vcpu? Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:09:29 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:09:29 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674379.1049217 (Exim 4.92) (envelope-from ) id 1rVVsa-0005sW-F6; Thu, 01 Feb 2024 12:09:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674379.1049217; Thu, 01 Feb 2024 12: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 1rVVsa-0005sP-B7; Thu, 01 Feb 2024 12:09:16 +0000 Received: by outflank-mailman (input) for mailman id 674379; Thu, 01 Feb 2024 12:09: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 1rVVsY-0005sJ-Os for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:09:14 +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 b6984565-c0fa-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 13:09:13 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40fc22f372cso1963085e9.1 for ; Thu, 01 Feb 2024 04:09: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 m21-20020a05600c4f5500b0040fb03f803esm4285986wmq.24.2024.02.01.04.09.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 04:09: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: b6984565-c0fa-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706789353; x=1707394153; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tH/k2x+4r+PxB4CU+/h65fC4pUhID4rLTMIEaTjk6kc=; b=N1ybM8BjZTsNbZJVm2PRgBJ68eC9SFowJseY04ZE6tzDoMtYuyX7MAB019B3hPtys7 4IcVZj1nxIY/2zPutO5zI2Rf2CumrEiepycntX7/d/4uGXzzO0N4ZhlalIUdtT+v7toE jmzLSiJH/wnjtyKj1d2iofJ8+ZPHeyLkYUEBy0i5epGiPvuQuD39EO+EQruuTPtEVkNW B/3x07UrjqRumjKibespMtYf64UlrappmbRlGzJdKUi+t4j/ZT8yFg082dn49gcqFv/Y pcZZP7fBuIMPDI4DeQntvepG2SsDYDBNRZDAdaLlKnEzhtHFDfFvRE0jNtst42mtdTxv n9ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706789353; x=1707394153; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tH/k2x+4r+PxB4CU+/h65fC4pUhID4rLTMIEaTjk6kc=; b=Kv+WxlcD2LLq+0Br+U4h9wQyRMB1X3mRZxoilawig/kO0ePCk6s3yIQYgwWojTYFDT ow211IFMwQl7nsTBt6GPxe2bPRAaE7IvwZFEQdh+eOTxGHDi31JOPzS1LC+UYBVBruRE +cMtlDgLb5rtIpDdJIgA/iniI3KR2CX06lDuEOaqalUhnW++MbzcQJfDD3A+useOvOZB UXReXNyo18vAxjv3GehZiRzk95mX5icRA9dLQebaiaOnesTSYvwUOhh+qMzxYywYwgp9 cy3D1eMaRWvXQ1tbXBEgcfXrHPA1GZlFpPnFMyjJAJfaLM70+swg3MQvxFL6ZAmVHQHq PinQ== X-Gm-Message-State: AOJu0YxGBmyVIVR100qH72SS/DjDNgQ5mt3RbLDh3N0t96PwPICYFMSK RT1jrqntFTzc9VSD6hnMWQhb1xgxiDv2jhevQZNt8pOipkG6OuiZg/UJaj4jaA== X-Google-Smtp-Source: AGHT+IFh1Xug2JOLJu4UIO6rBKLgHJ8iKOfKC4MlaViuy7J+pQcLHi7b+niGlM2CJVtBIroCGY1lMw== X-Received: by 2002:a05:600c:4288:b0:40e:fbc8:401 with SMTP id v8-20020a05600c428800b0040efbc80401mr4018713wmc.20.1706789352844; Thu, 01 Feb 2024 04:09:12 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCURuCvjHFZf6Q2hgZhVvg+SRJ3Jz4SHOk7TUi/MvgeKj79V3sTzZ+/dSh3NnjcK+sLZKofsVwBge2HzDit2M86H4Uw5ujpMuMCpwqIwYQfDbzLTENUpiMlbxTP2q7QOzbVPkfr/wVqmHluT5J3qJ/vHKBq9HKGGe8rq73uGFcirSSJ5Vw== Message-ID: <56822f9c-6156-4652-9de1-3d599e22c51a@suse.com> Date: Thu, 1 Feb 2024 13:09:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/8] VMX: tertiary execution control infrastructure Content-Language: en-US To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Andrew Cooper Cc: "xen-devel@lists.xenproject.org" , Wei Liu , Kevin Tian , Jun Nakajima References: <9dd23064-c79e-4a50-9c71-c0e73b189944@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 01.02.2024 12:50, Roger Pau Monné wrote: > On Thu, Jan 11, 2024 at 10:00:10AM +0100, Jan Beulich wrote: >> @@ -503,6 +538,9 @@ static int vmx_init_vmcs_config(bool bsp >> "Secondary Exec Control", >> vmx_secondary_exec_control, _vmx_secondary_exec_control); >> mismatch |= cap_check( >> + "Tertiary Exec Control", >> + vmx_tertiary_exec_control, _vmx_tertiary_exec_control); > > I know it's done to match the surrounding style, but couldn't you move > the name parameter one line up, and then limit the call to two lines? > > (I don't think it will compromise readability). You mean like this: mismatch |= cap_check("Tertiary Exec Control", vmx_tertiary_exec_control, _vmx_tertiary_exec_control); ? No, I view this as a mix of two possible styles. If the string literal was moved up, the other legitimate style would only be mismatch |= cap_check("Tertiary Exec Control", vmx_tertiary_exec_control, _vmx_tertiary_exec_control); aiui (again extending over 3 lines). Yet none of this is written down anywhere. But anyway - consistency with surrounding code trumps here, I think. >> @@ -2068,10 +2111,12 @@ void vmcs_dump_vcpu(struct vcpu *v) >> vmr(HOST_PERF_GLOBAL_CTRL)); >> >> printk("*** Control State ***\n"); >> - printk("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n", >> + printk("PinBased=%08x CPUBased=%08x\n", >> vmr32(PIN_BASED_VM_EXEC_CONTROL), >> - vmr32(CPU_BASED_VM_EXEC_CONTROL), >> - vmr32(SECONDARY_VM_EXEC_CONTROL)); >> + vmr32(CPU_BASED_VM_EXEC_CONTROL)); >> + printk("SecondaryExec=%08x TertiaryExec=%08lx\n", > > For consistency, shouldn't TertiaryExec use 016 instead of 08 (as it's > a 64bit filed). Perhaps, assuming we'll gets bits 32 and populated sooner or later. However, I view 16-digit literal numbers as hard to read, so I'd be inclined to insert a separator (e.g. an underscore) between the low and high halves. Thoughts? >> @@ -260,6 +262,13 @@ extern u32 vmx_vmentry_control; >> #define SECONDARY_EXEC_NOTIFY_VM_EXITING 0x80000000U >> extern u32 vmx_secondary_exec_control; >> >> +#define TERTIARY_EXEC_LOADIWKEY_EXITING BIT(0, UL) >> +#define TERTIARY_EXEC_ENABLE_HLAT BIT(1, UL) >> +#define TERTIARY_EXEC_EPT_PAGING_WRITE BIT(2, UL) >> +#define TERTIARY_EXEC_GUEST_PAGING_VERIFY BIT(3, UL) >> +#define TERTIARY_EXEC_IPI_VIRT BIT(4, UL) > > While at it, my copy of the SDM also has: > > #define TERTIARY_EXEC_VIRT_SPEC_CTRL BIT(7, UL) Ah yes, this must have appeared in the over 9 months that have passed since I originally wrote this patch. >> --- a/xen/arch/x86/include/asm/msr-index.h >> +++ b/xen/arch/x86/include/asm/msr-index.h >> @@ -347,6 +347,7 @@ >> #define MSR_IA32_VMX_TRUE_EXIT_CTLS 0x48f >> #define MSR_IA32_VMX_TRUE_ENTRY_CTLS 0x490 >> #define MSR_IA32_VMX_VMFUNC 0x491 >> +#define MSR_IA32_VMX_PROCBASED_CTLS3 0x492 > > Shouldn't this be added above the "Legacy MSR constants in need of > cleanup. No new MSRs below this comment." line? Now this is a question I'd like to forward to Andrew. Imo grouping the new MSR with the other VMX ones is more important than respecting that comment. But yes, I could of course add yet another patch to move the entire block up first ... >> --- a/xen/arch/x86/hvm/vmx/vmx.c >> +++ b/xen/arch/x86/hvm/vmx/vmx.c >> @@ -760,6 +760,12 @@ void vmx_update_secondary_exec_control(s >> v->arch.hvm.vmx.secondary_exec_control); >> } >> >> +void vmx_update_tertiary_exec_control(struct vcpu *v) > > const vcpu? Hmm, yes - overly blind copy-and-paste. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:11:54 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:11:54 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674383.1049227 (Exim 4.92) (envelope-from ) id 1rVVv6-0007k3-Om; Thu, 01 Feb 2024 12:11:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674383.1049227; Thu, 01 Feb 2024 12:11: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 1rVVv6-0007jw-M7; Thu, 01 Feb 2024 12:11:52 +0000 Received: by outflank-mailman (input) for mailman id 674383; Thu, 01 Feb 2024 12:11: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 1rVVv5-0007fE-3U for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:11:51 +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 1432c2dd-c0fb-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 13:11:50 +0100 (CET) Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-40fb63c40c0so7625455e9.2 for ; Thu, 01 Feb 2024 04:11:50 -0800 (PST) Received: from smtpclient.apple ([90.251.137.254]) by smtp.gmail.com with ESMTPSA id u18-20020a05600c19d200b0040fbc9a3405sm1492197wmq.0.2024.02.01.04.11.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2024 04:11: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: 1432c2dd-c0fb-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706789510; x=1707394310; 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=XzTNVroynWj1SFNgSOveOmhFes8MZYVA132LR0GQJKg=; b=fZ8DN/y3BJBshqeJaP+AqrudKL+ih7InvvvjXizdyFQiQGNlZVbMjjtkXIXqCF6yhy +o+4PxCuPcSz5XW+4xKoFz8EJxTwJk3DNAwCPArxMH6ILFPy/tZ5byYEFUyueavOT+Mf DSu3IP33V645O9BWqJBTch8EOAP4bt0O6aOWQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706789510; x=1707394310; 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=XzTNVroynWj1SFNgSOveOmhFes8MZYVA132LR0GQJKg=; b=WD7xIUB2DN1IBcOFhlb+dz5rrNcAlrVlFCSi6Y4oj2P1gxnG4NzmhxPU72eyUiCVyz JSG/1AYrMXfgIjyNQWTKgcoA3yeyt8Zu20HS+J6Yw7NeRxsbMZTpbyaXiIpFaldfvBtm atU90+gjRKaIKItvHJe4YOGibnQ+DTTFoYycpXgkcXAQQ6mY9MmVc0t2o5fyzFnuxnSc sP5V18vHMAX/2gzqbJyipdA8Jm2BCzTSgAtPK4GGAet1o8W0mg3GPKH9mEyYHNSpnmDU rLgARcVkW8fgLiaGqM3K2MR9K4NNAWySNqRqv7020fuTQEOgSGJ/QR1g6NXl5Gxgzu0x bP2w== X-Gm-Message-State: AOJu0Yxm4QPakgcfxC4KkmzlSWg8dQTlSIk1bK8TufjQP28PzGpq68VN 2oUjSaqC+6ImULtx4pekPAe9bkGUQTwkA/e83Vp7c24y2cC694YoRX3S2OkN84E= X-Google-Smtp-Source: AGHT+IEDKHUB7aduZzxaOJOYrYpySaXvUVlGyfCD8NywdNJcBBIeYNEQYFUNE4nZPcqtNUnz+oDPlw== X-Received: by 2002:a05:600c:35d3:b0:40e:fc29:f52f with SMTP id r19-20020a05600c35d300b0040efc29f52fmr3808286wmq.21.1706789509759; Thu, 01 Feb 2024 04:11:49 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCX8YTFu08UiZIBLLBhhKjDwQAhtWPsu5OdluSrJLI7AjTMvyi/4QJ9LErhP1grHuxDh3O5uwKnN/BvKmPSkf1nTm+NmuWYJiXDwT2LMlZonLpLzXXQw8uPeQ6jKRmyLi1rT2gCG+i40SzzCmmykOvfQUj0qNBvhcaduwj7wKRc4zyUsGZwjBqE99ms86awQztqCe4jhSOun2aKjCwN1bYy5WSBx Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: [PATCH v1 0/2] tools/ocaml: support OCaml 5.x, drop support for <=4.05 From: Edwin Torok In-Reply-To: Date: Thu, 1 Feb 2024 12:11:38 +0000 Cc: Christian Lindig , Xen-devel , Wei Liu , Anthony PERARD , Christian Lindig , David Scott Content-Transfer-Encoding: quoted-printable Message-Id: <2297C847-DE25-4D25-B1B0-57EFB8AA51DE@cloud.com> References: <4E9A23AB-5745-4A71-9013-156B6648025A@cloud.com> To: Andrew Cooper X-Mailer: Apple Mail (2.3774.400.31) > On 31 Jan 2024, at 10:55, Andrew Cooper = wrote: >=20 > On 31/01/2024 10:44 am, Christian Lindig wrote: >>> On 31 Jan 2024, at 10:42, Edwin T=C3=B6r=C3=B6k = wrote: >>>=20 >>> Fix building oxenstored with OCaml 5.x. >>> OCaml 5.x has removed some functions that have been deprecated for = many years, >>> in order to support OCaml 5.x we need to drop support for OCaml = 4.02. >>>=20 >>> Tested in gitlab CI (together with my other series): >>> = https://gitlab.com/xen-project/people/edwintorok/xen/-/pipelines/115830282= 7 >>>=20 >>> Edwin T=C3=B6r=C3=B6k (2): >>> oxenstored: fix build on OCaml 5.x >>> tools/ocaml: bump minimum version to OCaml 4.05 >>>=20 >>> tools/configure | 2 +- >>> tools/configure.ac | 2 +- >>> tools/ocaml/xenstored/disk.ml | 2 +- >>> 3 files changed, 3 insertions(+), 3 deletions(-) >>>=20 >>> --=20 >>> 2.43.0 >>>=20 >> Acked-by: Christian Lindig >=20 > It occurs to me that this is the kind of thing which should get a > CHANGELOG.md entry these days. Something like: >=20 > diff --git a/CHANGELOG.md b/CHANGELOG.md > index 1f55c9c72d10..fd7c8f5c6b82 100644 > --- a/CHANGELOG.md > +++ b/CHANGELOG.md > @@ -9,6 +9,7 @@ The format is based on [Keep a > Changelog](https://keepachangelog.com/en/1.0.0/) > ### Changed > - Changed flexible array definitions in public I/O interface headers > to not > use "1" as the number of array elements. > + - The minimum supported Ocaml toolchain version is now 4.05 > - On x86: > - HVM PIRQs are disabled by default. > - Reduce IOMMU setup time for hardware domain. Sounds good. Should this be mentioned in = https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_= Patch_Series? Best regards, =E2=80=94Edwin >=20 >=20 > ought to do. >=20 > Have we checked to see whether this drops Ocaml from any of the build > containers ? I can look into this later, haven=E2=80=99t tried rebuilding the = containers (the gitlab CI passed though) Best regards, =E2=80=94Edwin >=20 > ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:14:26 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:14:26 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674385.1049237 (Exim 4.92) (envelope-from ) id 1rVVxY-0008Jn-5U; Thu, 01 Feb 2024 12:14:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674385.1049237; Thu, 01 Feb 2024 12:14: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 1rVVxY-0008Jg-2R; Thu, 01 Feb 2024 12:14:24 +0000 Received: by outflank-mailman (input) for mailman id 674385; Thu, 01 Feb 2024 12:14: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 1rVVxW-0008Ja-O1 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:14:22 +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 6e758c66-c0fb-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 13:14:21 +0100 (CET) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5112cb7ae27so1564502e87.0 for ; Thu, 01 Feb 2024 04:14: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 v21-20020a05600c445500b0040faf3df118sm4353674wmn.32.2024.02.01.04.14.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 04:14: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: 6e758c66-c0fb-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706789661; x=1707394461; 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=poKUmijZjrU6z7E2d33cHjhbfbhs9SLZRbEIBTVo/DE=; b=cZz4DL6odwCfbDpN6b/XxqfZKdw4CKVICf6hUvbPbic2FZ/bTxOCFfwkwVk3mbRV54 2DHERwS6NM+lCe5aAm24vdFw/5Xtx/WEgPYruDpOSnqAGdsXT+p8s82vo8ZEgwmWI9pA csBP7rozOVuwrJ4Jg0GSfwAEOvIvSV3GNRPF/cOtmI5QcrTm6Wh2SfQQyen8fZED+2qM OF67JZTuUsQd9QpYlSGEWbpSoR4Dyhschywk+mJD1eX2gMkcl+WTsI1HdNwDSkXwiCZC g3l65MLRsED8/sSfdCfIUIfIiJCSFmwqJNEvJ00cgdPxbCTtBmNPf7RlQKgMfnJGBkvz Onqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706789661; x=1707394461; 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=poKUmijZjrU6z7E2d33cHjhbfbhs9SLZRbEIBTVo/DE=; b=rN+zNv+GXnLSrAIZIt3kd0HVfkExc8iXdmv80Q5s1e9kWdJokBwUTHW+iwASE9BRUb ikluuiu/a531U97Vjm15bX+YYaGv6wGjfKVXy0Tj4S8fpI6+/B+d+vQj4jQYC7Vz+NJe I2KyNryV7/RXaVSW2hT1Ry4rSwOEr8MV7gsIlcUbNFeyvV/bD0Xouor7TOGzsBcKbhQB OGQ/NEShhpYn3eXxql3q/qKdeBxhsfG+eBK8fbwIv724bAC/tyn1u5SOkfDMDKODE50U g2HNwNmBCQ7f76BFg3oQn91Gd7nFZgbg9iXyxntb2TB9qeylx1DcbmOaBA2dGYfrdcRa p3lg== X-Gm-Message-State: AOJu0YwYFHXSRdDFfcB6IMTkAdL7yilpwnLC9BvCyWGLs3kRO3DdS7AZ BDN3+fH6rUXjEzuvOruG6i4NCxXnrCzcRAOfOc5wDDmRwJKiFnFP6Yqkcw02qg== X-Google-Smtp-Source: AGHT+IHxdOAPTqinLiUUJR1DlPq06pe5+JRkvZDL1us9hsAfrJG1Mfm4gzq7a2zjjxHFmesTNYMzLQ== X-Received: by 2002:ac2:54b2:0:b0:511:1e60:8157 with SMTP id w18-20020ac254b2000000b005111e608157mr1554336lfk.10.1706789661344; Thu, 01 Feb 2024 04:14:21 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXmFke1JplbLXNMHDzsGpMZvvcuwb9pqNH3vnqcW8EWR2ZsBZyL/B79yvrezo5MNQB6EksE2yGCBKpTZtB8bljQhbTAl5YZ16FSx23ONv5sDWBI0NvEkFvXGdAdFDVYST8N+B/u43q0dsazw2VAeTitF8K2SWepHha12YokQbrzHuYoVowL8cLCYGVMXBYVqsq4mpTuBdSXTTL+f8sFi95p77lYzC20d4rD1M3eeK55EYBrVs/IptvSifPU1VspNtuohIgkT5Mbd8yaU82fDRkdh6d9zZhY Message-ID: <412fd2a2-4382-4131-92a5-cfb399f95f31@suse.com> Date: Thu, 1 Feb 2024 13:14:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/15] xen/common: add cache coloring common code Content-Language: en-US From: Jan Beulich To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-2-carlo.nonato@minervasys.tech> <42eabd87-b245-44e3-9945-40b1a5c5eaf5@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: <42eabd87-b245-44e3-9945-40b1a5c5eaf5@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 31.01.2024 16:57, Jan Beulich wrote: > On 29.01.2024 18:17, Carlo Nonato wrote: >> +Command line parameters >> +*********************** >> + >> +More specific documentation is available at `docs/misc/xen-command-line.pandoc`. >> + >> ++----------------------+-------------------------------+ >> +| **Parameter** | **Description** | >> ++----------------------+-------------------------------+ >> +| ``llc-coloring`` | enable coloring at runtime | >> ++----------------------+-------------------------------+ >> +| ``llc-way-size`` | set the LLC way size | >> ++----------------------+-------------------------------+ > > As a result of the above, I also find it confusing to specify "way size" > as a command line option. Cache size, number of ways, and cache line size > would seem more natural to me. Or, alternatively, have the number of colors be specifiable directly. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:19:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:19:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674390.1049246 (Exim 4.92) (envelope-from ) id 1rVW20-000157-My; Thu, 01 Feb 2024 12:19:00 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674390.1049246; Thu, 01 Feb 2024 12:19: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 1rVW20-000150-Jh; Thu, 01 Feb 2024 12:19:00 +0000 Received: by outflank-mailman (input) for mailman id 674390; Thu, 01 Feb 2024 12:18: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 1rVW1z-00013X-Lz for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:18:59 +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 12be9131-c0fc-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 13:18:57 +0100 (CET) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-40eacb4bfa0so7382585e9.1 for ; Thu, 01 Feb 2024 04:18: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 r7-20020adff107000000b0033b1ab837e1sm482525wro.71.2024.02.01.04.18.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 04:18: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: 12be9131-c0fc-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706789937; x=1707394737; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=eD5NDrU/PsoBq64jRmzK/ZATALjDnfifROpcrYlE12M=; b=JEbxKO2h9635JJWO1hgk+WORuQHq1btg8+a6Rc8/D8/3MC5HMQFI4Rpoz8UKn3mOoA Pkbv9mO/S3bweIZrlvmtH2FDsmyOeSwtNP8AjAOkDTERDszxmKFLvdD0Q7ReCBFJEi0S fYO8PT41xGpYbTKjtaZtSqoHvubI5hJb14dPaGNegil611mIYyZEg8lLhZKXLsKJxbRA QGZgRW40WpeHgy0F/SaWqklnBsoJdb1763Vg6wELjyILUFlaSJKC6mBseWhPZCHBjVOJ VFE0gu3yDxv0KcOYYeWpXhMW4AMjQ6FxMe5IeFL8aMMH5siDeXLx7l+pOY+TRH1fnUGa exgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706789937; x=1707394737; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eD5NDrU/PsoBq64jRmzK/ZATALjDnfifROpcrYlE12M=; b=QFVcr/fQ4yfhdmi+XmsuLYtGq3N+1aQaOW7xm2Rv7UPiUVvh4kDqlSau9L7V0KCzWG gGekgmNYNC+Sf1f+LlSIiCkrZ7TZpzfj5jgMnUwI51plEWO1nqwfZe7SO9TP0xGDgWqw zZXk/19bcyVJFFnM2x+asX/Lu7vdS4gttQoLxV4TPylsLbvqv+F4NPqk5GBKLUJLywxA b1Uh/ty6vOlMgbuGW2lz6agX213sRUG+guXSakfl9F3C+U3djneU4ffCzQDBBwfIdIqR dgciKlj+xSGT/TNLGawvlThxnVFmwyb6qX9qIojrFC8esODJTz/0Tad2ITogwrZ1lm5c 6UIg== X-Gm-Message-State: AOJu0Ywd1r/eimsTb6fheW88ZgBJU/gQO7zOQbIpg/bWD/IK0zYiNHCY KXITvSu1kG+lqnJmE5+g0Lw7J6ChNk2uDId99/wG4dTt8RMTjNO5UE8mmeuqTA== X-Google-Smtp-Source: AGHT+IF/p4o/Xb8wZmChDdC74b5tDL6KyfWTBri+huEg8aWAzIul24aPxXevexGDeI1UJEqM1anbaA== X-Received: by 2002:a05:600c:5486:b0:40f:2d7:287c with SMTP id iv6-20020a05600c548600b0040f02d7287cmr1475583wmb.8.1706789937022; Thu, 01 Feb 2024 04:18:57 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUNUvMIJtlH1LlNw03rIBTiyobe8YrzJIEWgsx2GKoUChIqVmtowcM/clP0WJ7ot75B+qvwekFTWTtkNlpRQqVoda8Vd+dA8JJNav+juC6rbfiBe2ReHsT8TQOYvm4dso10lYz02GaA+0HrylZuXaIoTj28mkfvWx5lgs48Ycml8LPjZyrtNbvlGxsKzQQguvrN4mPlSang167/dH9aCOgsGKa86QQV8sXS/lITIcFkxvkmqYfsoMW8ua+CvaJy4UabjOTJ/X9bxC1Iy4zmpbQJrZhu6C4t Message-ID: Date: Thu, 1 Feb 2024 13:18:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/15] xen/common: add cache coloring common code Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-2-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:17, Carlo Nonato wrote: > --- /dev/null > +++ b/docs/misc/cache-coloring.rst > @@ -0,0 +1,87 @@ > +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. > + > +To compile LLC coloring support set ``CONFIG_LLC_COLORING=y``. > + > +If needed, change the maximum number of colors with > +``CONFIG_NR_LLC_COLORS=``. > + > +Compile Xen and the toolstack and then configure it 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 allows eliminating this > +mutual interference, and thus guaranteeing higher and more predictable > +performances for memory accesses. Since you say "eliminating" - what about shared mid-level caches? What about shared TLBs? Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:20:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:20:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674393.1049257 (Exim 4.92) (envelope-from ) id 1rVW3E-0002qf-4P; Thu, 01 Feb 2024 12:20:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674393.1049257; Thu, 01 Feb 2024 12: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 1rVW3E-0002qY-0y; Thu, 01 Feb 2024 12:20:16 +0000 Received: by outflank-mailman (input) for mailman id 674393; Thu, 01 Feb 2024 12:20:15 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVW3D-0002p3-BB for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:20:15 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVW37-0008HE-Be; Thu, 01 Feb 2024 12:20:09 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rVW37-0002Mi-4i; Thu, 01 Feb 2024 12: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" 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=fRFuwtEwNy6+DYwm/cJrzgMhWIr5XdvdCViTG3PTGDQ=; b=Pd84zAaBe96ZSB1Tx8w5uTdpal d/+vtBbEiDAl+GCFp8KKrPijfZJNf92UADMXvu2iPLbabj5SgGwZxpCtWI0vIR/uRog3qRYC6x865 Rs9yYtxAUi1N6J+TdBtGaBWC8y3shLasWSNt5oWaSuRgHDPjh5RpkuW053pUeaqneVSw=; Message-ID: <167f0c7a-e037-446c-82f8-2584e35a7af1@xen.org> Date: Thu, 1 Feb 2024 12:20:06 +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 , Stefano Stabellini , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Peng Fan 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> From: Julien Grall In-Reply-To: <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@actia.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 31/01/2024 15:32, John Ernberg wrote: > Hi Julien, Hi John, > On 1/31/24 13:22, Julien Grall wrote: >> Hi, >> >> On 31/01/2024 11:50, John Ernberg wrote: >>> When using Linux for dom0 there are a bunch of drivers that need to do >>> SMC >>> SIP calls into the PSCI provider to enable certain hardware bits like the >>> watchdog. >> >> Do you know which protocol this is under the hood. Is this SCMI? > > I think I confused myself here when I wrote the commit log. > > The EL3 code in our case is ATF, and it does not appear to be SCMI, nor > PSCI. The register usage of these SMC SIP calls are as follows: > a0 - service > a1 - function > a2-a7 - args > > In ATF the handler is declared as a runtime service. > > Would the appropriate commmit message here be something along the lines > of below? > """ > 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. > """ It reads better thanks. [...] >> But even if we restrict to dom0, have you checked that none of the SMCs >> use buffers? > I haven't found any such instances in the Linux kernel where a buffer is > used. Adding a call filtering like suggested below additions of such > functions can be discovered and adapted for if they would show up later. >> >> Rather than providing a blanket forward, to me it sounds more like you >> want to provide an allowlist of the SMCs. This is more futureproof and >> avoid the risk to expose unsafe SMCs to any domain. >> >> For an example, you can have a look at the EEMI mediator for Xilinx. > > Ack. Do you prefer to see only on SMCCC service level or also on > function level? (a1 register, per description earlier) I am not sure. It will depend on whether it is correct to expose *all* the functions within a service level and they have the same format. If you can't guarantee that, then you will most likely need to allowlist at the function level. Also, do you have a spec in hand that would help to understand which service/function is implemented via those SMCs? Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Feb 01 12:30:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 12:30:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674405.1049267 (Exim 4.92) (envelope-from ) id 1rVWDM-0005Lt-5H; Thu, 01 Feb 2024 12:30:44 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674405.1049267; Thu, 01 Feb 2024 12:30: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 1rVWDM-0005Lm-25; Thu, 01 Feb 2024 12:30:44 +0000 Received: by outflank-mailman (input) for mailman id 674405; Thu, 01 Feb 2024 12:30: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 1rVWDL-0005Lg-3A for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12:30:43 +0000 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [2607:f8b0:4864:20::42b]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id b534da19-c0fd-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 13:30:40 +0100 (CET) Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-6ddc1b30458so720756b3a.1 for ; Thu, 01 Feb 2024 04:30: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: b534da19-c0fd-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706790639; x=1707395439; 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=MNNe40aDhpyf7c0R61dDLN1CMdR/83Z6jEtpSATxBS4=; b=jSXm+5Dq4ym8TPRAfVDS3fbVV7NYeCBkrEAxim0C6shcE7pnL3xJ3SuLmnnSBmoN// y/MVdyF3IBbCek4OD90mZZixbeRh2ev0hg7hydsVYq43aAMHcf6/JfU9nuNJLaFCp2nY 6GMEI1kjRXNZuA0OPvW0EhY6l+dB2j4mq8PXNuGKwXXLHezNY31+HoTgWLjLcJO7gPPy 1uvRCWbTyKNfOTIbxmAV2HmSSSgM7cmogiEGBg95CIJi3EPz+UUGUAp/vsf4iZJuaVGB t35hgp3uO+9d8CSV/0jrtt/Q2if+TtZu9RtIPRJTeUQD1OJ5BNBVWx6TBAE0u+pDa/r8 HnXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706790639; x=1707395439; 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=MNNe40aDhpyf7c0R61dDLN1CMdR/83Z6jEtpSATxBS4=; b=R/5/UwfH6SLO5nsXycSNzoeBfhQa28Qbd754a0ecPbhzNcfTTZ/LEtkOnJJyvbBLUp g4ib+7cVGjy8aD/OUWCVBs3lE2wKBDptHKhqODzKWH3vd9258G4p4niCk57lle7rhZhv M+CNO7D+61pPQ1rZOEnaKKlZpDhuOkjAgw2Onr3WpkXzpOuOodaXlg2wYbSyQ50ytsam 1Is9BznbuZ4cLLs1nZlDmKJamSitHzk5SArI4q28xxmgViCRv8t4TnKHpcbohRT4izI8 34DtoUnzLZs0GPz3FEu9B7git3NFHF8d3nwRKgST8Bz1eW8TcjbIEtV008MLyB/jf+2B Q0QA== X-Gm-Message-State: AOJu0Yybt4yvrrYReGI92XfZK1Ee5ASWhqq0TG2BUrNvpJFOZ5jrF1fs cfrq7Wr9w3qN2g70fgF4bNujYo/SQXwL88BJsiFyi7hSqZsn441Eg4hpvxQ40NunzYnobKKal9+ 2L98Lq4GQqevfSQITxRFT4g41pcSvlQVpOQkZNw== X-Google-Smtp-Source: AGHT+IGGofdZQxqikVe1bre/Xj1M34eesDnF1lZASV+6c77b+PD/3kvWcUxdr2RYddnUex8ieuor7XAswonzV0qmI4o= X-Received: by 2002:a05:6a00:2ea7:b0:6db:dc74:d6e with SMTP id fd39-20020a056a002ea700b006dbdc740d6emr5098643pfb.17.1706790638574; Thu, 01 Feb 2024 04:30:38 -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: <214585d5-689d-4ba6-bd48-359428a7ed8f@amd.com> From: =?UTF-8?Q?S=C3=A9bastien_Chaumat?= Date: Thu, 1 Feb 2024 13:30:26 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Mario Limonciello Cc: Jan Beulich , xen-devel@lists.xenproject.org, Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="000000000000b7e0af061051296f" --000000000000b7e0af061051296f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I spotted the following warning for IRQ7 (along with IRQ6 and 10) [ 0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type function for IRQ 7 (IR-IO-APIC) This comes from kernel/irq/manage.c int __irq_set_trigger(struct irq_desc *desc, unsigned long flags) { struct irq_chip *chip =3D desc->irq_data.chip; int ret, unmask =3D 0; if (!chip || !chip->irq_set_type) { /* * IRQF_TRIGGER_* but the PIC does not support multiple * flow-types? */ pr_debug("No set_type function for IRQ %d (%s)\n", irq_desc_get_irq(desc), chip ? (chip->name ? : "unknown") : "unknown"); return 0; } Could this have a role in the IRQ misconfiguration by xen ? Le lun. 22 janv. 2024 =C3=A0 21:59, Mario Limonciello a =C3=A9crit : > On 1/22/2024 11:06, S=C3=A9bastien Chaumat wrote: > > > > > > Le mer. 17 janv. 2024 =C3=A0 03:20, Mario Limonciello > > > a =C3=A9= crit : > > > > On 1/16/2024 10:18, Jan Beulich wrote: > > > On 16.01.2024 16:52, S=C3=A9bastien Chaumat wrote: > > >> Le mar. 2 janv. 2024 =C3=A0 21:23, S=C3=A9bastien Chaumat > > > a > > >> =C3=A9crit : > > >> > > >>> > > >>> output of gpioinfo > > >>>> > > >>>> kernel alone : > > >>>> > > >>>> line 5: unnamed input active-low > > consumer=3Dinterrupt > > >>>> line 84: unnamed input active-low > > consumer=3Dinterrupt > > >>>> > > >>>> xen: > > >>>> > > >>>> line 5: unnamed input active-low > > >>>> line 84: unnamed input active-low > > >>>> > > >>>> xen with skipping IRQ7 double init : > > >>>> > > >>>> line 5: unnamed input active-low > > consumer=3Dinterrupt > > >>>> line 84: unnamed input active-low > > >>>> > > >>>> > > >>>> So definitely progressing. > > >>>> > > >>> > > >>> Checking /sys/kernel/irq/7 > > >>> > > >>> kernel alone : > > >>> actions: pinctrl_amd > > >>> chip_name: IR-IO-APIC > > >>> hwirq: 7 > > >>> name: fasteoi > > >>> per_cpu_count: 0,0,0,0,0,20,0,0,0,0,0,0,0,0,0,0 > > >>> type: level > > >>> wakeup: enabled > > >>> > > >>> xen skipping IRQ7 double init : > > >>> > > >>> actions: pinctrl_amd > > >>> chip_name: xen-pirq > > >>> hwirq: > > >>> name: ioapic-level > > >>> per_cpu_count: 0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0 > > >>> type: edge > > >>> wakeup: disabled > > >>> > > >>> So the skip of IRQ7 in pci_xen_initial_domain() sets the > > correct handler > > >>> (IIUC xen uses the ioapic-level and handles the eoi > > separately), but not > > >>> the correct type (still edge). > > >>> I guess this may explains the results above. > > >>> > > >>> > > >> Mario (in CC) patched the pinctrl_amd to flush pending > > interrupt before > > >> starting the driver for the GPIO. > > >> > > >> This helped in the sense of there's no more pending interrupt > > on IRQ7 > > >> (whatever the handler is, level or edge) but then the touchpad > > is not > > >> detected by i2c-hid. > > >> > > >> Is there any work in progress related to the incorrect IRQ > > configuration ? > > > > > > I'm not aware of any. As per my recollection it's still not > entirely > > > clear where in the kernel things go astray. And to be honest I > don't > > > feel comfortable trying to half-blindly address this, e.g. by > trying > > > to circumvent / defer the early setting up of the low 16 IRQs. > > > > > > Jan > > > > Shot in the dark - but could this be a problem where PCAT_COMPAT fr= om > > the MADT is being ignored causing PIC not to be setup properly in t= he > > Xen case? > > > > See https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/ > > for some context= . > > > > At least we know that no MADT override is found by xen for INT7 as no > > INT_SRC_OVR message is printed. > > > > Do we expect one @Mario Limonciello > ? > > No; the INT_SRV_OVR you'll see on Framework 13 AMD is on IRQ 2 and IRQ 9. > > --000000000000b7e0af061051296f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I spotted the following warning for IRQ7 (along with = IRQ6 and 10)

[ =C2=A0 =C2=A00.686073] fed= ora kernel: __irq_set_trigger: genirq: No set_type function for IRQ 7 (IR-I= O-APIC)

This comes from kernel/irq/manage.c<= /div>


int __= irq_set_trigger(struct irq_desc *desc, = unsigned long flags)
{
struct irq_chip *chip =3D desc->irq= _data.chip;
<= span style=3D"color:rgb(0,0,0)"> int ret, unmask =3D 0;

= if (!chip || !chip->irq_set_type) {
/*
* IRQF_TRIGGER_* but the PIC d= oes not support multiple
* flow-types?
*/
pr_debug("No set_type function for IRQ %d (%s)\n",
= irq_desc_get_irq(des= c),
chip ? (chip-><= span style=3D"color:rgb(0,0,0)">name ? : "unknown") : "unkn= own");
= return 0;
}

Could this have a r= ole in the IRQ misconfiguration by xen ?




Le=C2=A0lun. 22 janv. 2024 =C3=A0=C2=A021:59, Mario Limonci= ello <mario.limonciello@amd= .com> a =C3=A9crit=C2=A0:
On 1/22/2024 11:06, S=C3=A9bastien Chaumat wrote:
>
>
> Le=C2=A0mer. 17 janv. 2024 =C3=A0=C2=A003:20, Mario Limonciello
> <mar= io.limonciello@amd.com <mailto:mario.limonciello@amd.com>> a =C3=A9cri= t=C2=A0:
>
>=C2=A0 =C2=A0 =C2=A0On 1/16/2024 10:18, Jan Beulich wrote:
>=C2=A0 =C2=A0 =C2=A0 > On 16.01.2024 16:52, S=C3=A9bastien Chaumat w= rote:
>=C2=A0 =C2=A0 =C2=A0 >> Le mar. 2 janv. 2024 =C3=A0 21:23, S=C3= =A9bastien Chaumat
>=C2=A0 =C2=A0 =C2=A0<euidzero@gmail.com <mailto:euidzero@gmail.com>> a
>=C2=A0 =C2=A0 =C2=A0 >> =C3=A9crit :
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0output of gpioinfo
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> kernel alone :
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 =C2=A05: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-= low
>=C2=A0 =C2=A0 =C2=A0consumer=3Dinterrupt
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 84: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-low >=C2=A0 =C2=A0 =C2=A0consumer=3Dinterrupt
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> xen:
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 =C2=A05: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-= low
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 84: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-low >=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> xen with skipping IRQ7 double ini= t :
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 =C2=A05: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-= low
>=C2=A0 =C2=A0 =C2=A0consumer=3Dinterrupt
>=C2=A0 =C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= line=C2=A0 84: unnamed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0input active-low >=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> So definitely progressing.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> Checking /sys/kernel/irq/7
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> kernel alone :
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0actions: pinctrl_amd
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0chip_name: IR-IO-APIC
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0hwirq: 7
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0name: fasteoi
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0per_cpu_count: 0,0,0,0,0,= 20,0,0,0,0,0,0,0,0,0,0
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0type: level
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0wakeup: enabled
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> xen skipping IRQ7 double init :
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> actions: pinctrl_amd
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0chip_name: xen-pirq
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0hwirq:
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0name: ioapic-level
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0per_cpu_count: 0,0,0,0,0,= 0,1,0,0,0,0,0,0,0,0,0
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0type: edge
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0wakeup: disabled
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> So the skip of IRQ7 in pci_xen_initia= l_domain() sets the
>=C2=A0 =C2=A0 =C2=A0correct handler
>=C2=A0 =C2=A0 =C2=A0 >>>=C2=A0 =C2=A0(IIUC xen uses the ioapic= -level and handles the eoi
>=C2=A0 =C2=A0 =C2=A0separately), but not
>=C2=A0 =C2=A0 =C2=A0 >>> the correct type (still edge).
>=C2=A0 =C2=A0 =C2=A0 >>> I guess this may explains the results= above.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0Mario (in CC) patched the pin= ctrl_amd to flush pending
>=C2=A0 =C2=A0 =C2=A0interrupt before
>=C2=A0 =C2=A0 =C2=A0 >> starting the driver for the GPIO.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> This helped in=C2=A0 the sense of there&#= 39;s no more pending interrupt
>=C2=A0 =C2=A0 =C2=A0on IRQ7
>=C2=A0 =C2=A0 =C2=A0 >> (whatever the handler is, level or edge) = but then the touchpad
>=C2=A0 =C2=A0 =C2=A0is not
>=C2=A0 =C2=A0 =C2=A0 >> detected by i2c-hid.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Is there any work in progress related to = the incorrect IRQ
>=C2=A0 =C2=A0 =C2=A0configuration ?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I'm not aware of any. As per my recollect= ion it's still not entirely
>=C2=A0 =C2=A0 =C2=A0 > clear where in the kernel things go astray. A= nd to be honest I don't
>=C2=A0 =C2=A0 =C2=A0 > feel comfortable trying to half-blindly addre= ss this, e.g. by trying
>=C2=A0 =C2=A0 =C2=A0 > to circumvent / defer the early setting up of= the low 16 IRQs.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Jan
>
>=C2=A0 =C2=A0 =C2=A0Shot in the dark - but could this be a problem wher= e PCAT_COMPAT from
>=C2=A0 =C2=A0 =C2=A0the MADT is being ignored causing PIC not to be set= up properly in the
>=C2=A0 =C2=A0 =C2=A0Xen case?
>
>=C2=A0 =C2=A0 =C2=A0See https://lore.kernel.org/= all/875y2u5s8g.ffs@tglx/
>=C2=A0 =C2=A0 =C2=A0<https://lore.kernel.org/= all/875y2u5s8g.ffs@tglx/> for some context.
>
> At least we know that no MADT override is found by xen for INT7 as no =
> INT_SRC_OVR message is printed.
>
> Do we expect one @Mario Limonciello <mailto:mario.limonciello@amd.com>= =C2=A0 ?

No; the INT_SRV_OVR you'll see on Framework 13 AMD is on IRQ 2 and IRQ = 9.

--000000000000b7e0af061051296f-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:00:03 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:00:03 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674409.1049277 (Exim 4.92) (envelope-from ) id 1rVWfX-0003fT-Dn; Thu, 01 Feb 2024 12:59:51 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674409.1049277; Thu, 01 Feb 2024 12: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 1rVWfX-0003fM-9x; Thu, 01 Feb 2024 12:59:51 +0000 Received: by outflank-mailman (input) for mailman id 674409; Thu, 01 Feb 2024 12: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 1rVWfV-0003do-Ca for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 12: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 c5d893dc-c101-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 13:59:45 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a3510d79ae9so108924266b.0 for ; Thu, 01 Feb 2024 04:59: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 un6-20020a170907cb8600b00a36a7f0f087sm853168ejc.222.2024.02.01.04.59.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 04:59: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: c5d893dc-c101-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706792385; x=1707397185; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zl2cW3Nf4pRC//h1O/iq1g877AMcMR/l+E8T3gdpu4c=; b=WwCQMQpPaJNq3qRfK4HKLccSKMqIzeHhBm3Li6rMDu5+nrBCvvOHoV0s+pY4Q8JhBv hN72jbOvfBqzTHXpBqsv+qZuW87AF3Xctz+/8rqGDBWP/4DY+NMaO47xluzDdpKHwRuG WN4t8ny1hJnEdxrCI7dmjzMgR3u/7LCvL1+Hd+32scGf0mnfDuLZOqKwxLTGiYyWysfR a4exlMcICb9Ffv0Mdk3VZ7R7GtWIeT+b4OE/DfRCgiXm3/dPgsXJB+aYOwyFGhSvrqcz 4cGsN1hFCpam1YHSvPCkVJqFsUDW0PYQOBkimiKnWCF1bo0Ke8zv4CBVIyW6tBhLZFda aKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706792385; x=1707397185; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zl2cW3Nf4pRC//h1O/iq1g877AMcMR/l+E8T3gdpu4c=; b=loINMDXLkEvILakdMdGotnWzqKyfBJpPGM+qpWpgUW9PGCffKvoyf4DRuLVdyg/eYP MQooYlDVUC3J2kdKuj8OOst7nk8iki0gBj17c0MVFYTaJQe2nVlO+yWBOWePttfdeckd B0fdRz8hZCKfFLBfZpAbaEdlKHEJrM6pqe7nDhZo6c04RkTgxmnA1fQVV40KAOivHoHb 2DhjYckNO1+4NT0eO0F87mmdRvBs4DNBYzBnq9FvDeoV9NLMDW6xMVe7Dzk0UY05YshD NrZ5NmlJUKcJvRQmX+z+7gRn+hs8AT2WHLWzaKFdscwEwi4F2byXmL44nfC+lxLqEpTU /zmQ== X-Gm-Message-State: AOJu0YwtMbAZmRygDpYl64t8UGT/OaNckJbt3rOZPGSOaJL2u4wRl++u d/xV0mDG41oOBYHqOSK0KgkN7mKVHH14w/mDVuCNiEp2gnI6DJw/WxWJlszFZQ== X-Google-Smtp-Source: AGHT+IGjwjGs0v1oXiJdD8mOW31gkXxFyk3rQD2SskaB5KSot/lGzXDyFgsWowu6ah8cajrXrFalzg== X-Received: by 2002:a17:906:a883:b0:a36:5079:d6c9 with SMTP id ha3-20020a170906a88300b00a365079d6c9mr3338004ejb.76.1706792384939; Thu, 01 Feb 2024 04:59:44 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXMv61hXbNFRRGNxKyhVFyOzUYucwqmMJh7MEuQw8gspOkU4MzN9MwCijeDbkN5hQ5zqGi/3nGaG+efacx08Z4JOatK1pioa50xojOtAQ1ZZ2f7Y7OK3mJ4Up49Ardy5KLUsN9xijDO5IL3abIN6I68+3z7IArUef5p3J2DkofcdSY81mYQGPor4BabVq6G7hvytIuUFvpTRzEoB5JFCe/aPYAT8cEzqvr2IYxHXcYZtlqRlB69Xh/hgSWbQQlDTuigkcmKDzHZFFCM7kachH4wGiO9ohms Message-ID: <749799db-de6f-4ca8-bab1-67468f97929b@suse.com> Date: Thu, 1 Feb 2024 13:59:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/15] xen/common: add cache coloring common code Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-2-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:17, Carlo Nonato wrote: > --- a/xen/arch/Kconfig > +++ b/xen/arch/Kconfig > @@ -31,3 +31,20 @@ 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 > + > +config NR_LLC_COLORS > + int "Maximum number of LLC colors" > + range 2 1024 What's the reasoning behind this upper bound? IOW - can something to this effect be said in the description, please? > + 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 needed in the general case. Aiui while not outright wrong, non-power-of-2 values are meaningless to specify. Perhaps that is worth mentioning (if not making this a value that's used as exponent of 2 in the first place)? As to the default and its description: As said for the documentation, doesn't what this corresponds to also depend on cache line size? Even if this was still Arm-specific rather than common code, I'd question whether now and forever Arm chips may only use one pre-determined cache line size. > --- /dev/null > +++ b/xen/common/llc-coloring.c > @@ -0,0 +1,87 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Last Level Cache (LLC) coloring common code > + * > + * Copyright (C) 2022 Xilinx Inc. > + */ > +#include > +#include > +#include > + > +bool __ro_after_init llc_coloring_enabled; > +boolean_param("llc-coloring", llc_coloring_enabled); The variable has no use right now afaics, so it's unclear whether (a) it is legitimately non-static and (b) placed in an appropriate section. > +/* Size of an LLC way */ > +static unsigned int __ro_after_init llc_way_size; > +size_param("llc-way-size", llc_way_size); > +/* Number of colors available in the LLC */ > +static unsigned int __ro_after_init max_nr_colors = CONFIG_NR_LLC_COLORS; > + > +static void print_colors(const unsigned int *colors, unsigned int num_colors) > +{ > + unsigned int i; > + > + printk("{ "); > + for ( i = 0; i < num_colors; i++ ) { Nit (style): Brace placement. > + unsigned int start = colors[i], end = colors[i]; > + > + printk("%u", start); > + > + for ( ; > + i < num_colors - 1 && colors[i] + 1 == colors[i + 1]; To reduce the number of array accesses, may I suggest to use "end + 1" here instead of "colors[i] + 1"? (The initializer of "end" could also be "start", but I guess the compiler will recognize this anyway.) This would then (imo) also better justify the desire for having "end" in the first place. > + i++, end++ ); Imo for clarity the semicolon want to live on its own line. > +static void dump_coloring_info(unsigned char key) This being common code now, I think it would be good practice to have cf_check here right away, even if for now (for whatever reason) the feature is meant to be limited to Arm. (Albeit see below for whether this is to remain that way.) > +void __init llc_coloring_init(void) > +{ > + if ( !llc_way_size && !(llc_way_size = get_llc_way_size()) ) > + panic("Probed LLC coloring way size is 0 and no custom value found\n"); > + > + /* > + * The maximum number of colors must be a power of 2 in order to correctly > + * map them to bits of an address, so also the LLC way size must be so. > + */ > + if ( llc_way_size & (llc_way_size - 1) ) > + panic("LLC coloring way size (%u) isn't a power of 2\n", llc_way_size); > + > + max_nr_colors = llc_way_size >> PAGE_SHIFT; With this unconditionally initialized here, what's the purpose of the variable's initializer? > + 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); I'm not convinced of panic()ing here (including the earlier two instances). You could warn, taint, disable, and continue. If you want to stick to panic(), please justify doing so in the description. Plus, if you panic(), shouldn't that be limited to llc_coloring_enabled being true? Or - not visible here, due to the lack of a caller of the function - is that meant to be taken care of by the caller (to not call here when the flag is off)? I think it would be cleaner if the check lived here; quite possibly that would then further permit the flag variable to become static. > + register_keyhandler('K', dump_coloring_info, "dump LLC coloring info", 1); I'm also not convinced of using a separate key for this little bit of information. How about attaching this to what 'm' or 'H' produce? > + arch_llc_coloring_init(); > +} > + > +void domain_dump_llc_colors(const struct domain *d) > +{ > + printk("Domain %pd has %u LLC colors: ", d, d->num_llc_colors); %pd resolves to d - why "Domain" as a prefix? And really - why the domain identifier in the first place? All surrounding information is already for this very domain. > + print_colors(d->llc_colors, d->num_llc_colors); Imo this (or perhaps even the entire function) wants skipping when num_llc_colors is zero, which would in particular also cover the !llc_coloring_enabled case. > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -626,6 +626,11 @@ struct domain > > /* Holding CDF_* constant. Internal flags for domain creation. */ > unsigned int cdf; > + > +#ifdef CONFIG_LLC_COLORING > + unsigned const int *llc_colors; const unsigned int * please. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:30:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:30:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674415.1049287 (Exim 4.92) (envelope-from ) id 1rVX9H-0003me-Qx; Thu, 01 Feb 2024 13:30:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674415.1049287; Thu, 01 Feb 2024 13: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 1rVX9H-0003mX-NP; Thu, 01 Feb 2024 13:30:35 +0000 Received: by outflank-mailman (input) for mailman id 674415; Thu, 01 Feb 2024 13:30: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 1rVX9H-0003mR-0j for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:30:35 +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 13558d97-c106-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:30:33 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-55f19a3ca7aso3899898a12.1 for ; Thu, 01 Feb 2024 05:30: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 ty8-20020a170907c70800b00a353d1a19a9sm6117061ejc.191.2024.02.01.05.30.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 05:30: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: 13558d97-c106-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706794233; x=1707399033; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1YU4wWiLq7QGViTJ8twYyIsIRAeG5ZtwwK8ol7Dc0W4=; b=SGazCaxJT2cSx/06lN6VXMdvWCYGuQ0Vw5ZPuvebC2UU28pP0smR//FbRmAz14iLey t48jp7IA9J60klspTK5GELimKepMhiWVbbAhPMY9f9gB8irj9TFSu0GNlv5v/B7G2kez NN11hOSB2/v9+pbm4DoboUGANTujMRxroNS1X6tC69iEwEEuqftnJKyZ5sX4wjIVC9V5 6J64E8OkE51nGg+jUbu9lBHlvaBX+y+NqIzDY2CaA9BCai0oJHLmzMt5cWS34AjU4V+Z iXT+2fc+2ybAu0fOg1Mk4Lp0EpQA3Y7RQTTKGt5lOG9d1TCPla6YlN58E5zmszADgqlu zH/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706794233; x=1707399033; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1YU4wWiLq7QGViTJ8twYyIsIRAeG5ZtwwK8ol7Dc0W4=; b=dUiFUZTCVHFBj+le3vtgbHUOGpGn4cfwxXArpfYyPrjmPXEgNdcbddMWj99fXfQYUr xPQyzlAmG3ofoHetktmdSa+BuTxpFMlY2vwREX+YCYeTGnE5UysJI6ZByAFdhGoJebg9 wKKR1SHjDilkx87j7wmlHdfBLXlhFP6R2Yu2BCp/7xZextwxkp9tgAl9hrsv0fOprHnC tYMS4/APCQaCUaVF2DjRSlUugV6qKwL/GTumus4/UuQQKIIX54/4G7UysZcbjDkwG0xR gXYz6QyL4yhypbd68z+AZjprX/9v7wqEvUhTSZPG5kc6faVFxqzzCwuSHVOXiPqsCOuG Lu+w== X-Gm-Message-State: AOJu0Yzfz9q5x76b/aPa/wmHQdEkxhAs/eKiZhmK9oIh918MjhKH5h6K LVdhs322MLNsOO5xJG4NRTGwRq1HxzbrUbwDOYS65r4XiU4gabgfbP0JOcly4g== X-Google-Smtp-Source: AGHT+IG0zbt/Kby5a0Ec6Dd4UsqOjpX3KN0wfRbWosqH+TkEDgZfimjmzIjRrxyxy83V9JlR7ln9EQ== X-Received: by 2002:a17:907:d50b:b0:a36:85b9:cd1b with SMTP id wb11-20020a170907d50b00b00a3685b9cd1bmr4066674ejc.25.1706794232927; Thu, 01 Feb 2024 05:30:32 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUvwMi1o4O1O3XGlvYlCzXDYOfiWfPTcXsJzKOvVrT3BOnXf2gCPv6fW/trBSunXLl9f+P+x61r9OstYSLn+Mxc9dor+2jRellnSxHTVaUglgo3mWh0Qjc/tV16PNeN45uj+0844kuxe5DvKlnGbwg9Q1Aj0cT/vCWj1LeNppUlwy9U+Sjco9WYDrfJGlGtJ96UqSw1ZM0283As9U23OPBHmw61neh/J+8JrYHnvSjFQFEtvKg1Rku6oU6gS2qarnXqGLFDNj4XpyME/um0wiovvPG8mFO6nD0UpCHSoBW3kk+uBBlLonRfQJQx+4H5WwsB7VAvodmyuwkV1JrQPPwssJ0L2jgElbaxMWACbZ3VQTaKqMJlxk8FTY5vYAhIKr4LEw== Message-ID: Date: Thu, 1 Feb 2024 14:30:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 04/15] xen/arm: add Dom0 cache coloring support Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-5-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > 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. What implications does this have? > --- 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 options is available only when > +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available > +colors are used. Even Arm already has a "dom0=" option. Is there a particular reason why this doesn't become a new sub-option there? As to meaning: With just a single , that's still a color value then (and not a count of colors)? Wouldn't it make sense to have a simpler variant available where you just say how many, and a suitable set/range is then picked? Finally a nit: "This option is ...". > @@ -2188,10 +2190,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); As for the earlier patch, I find panic()ing here dubious. You can continue quite fine, with a warning and perhaps again tainting the system. > --- a/xen/common/llc-coloring.c > +++ b/xen/common/llc-coloring.c > @@ -17,6 +17,63 @@ size_param("llc-way-size", llc_way_size); > /* Number of colors available in the LLC */ > static unsigned int __ro_after_init max_nr_colors = CONFIG_NR_LLC_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 parse_color_config(const char *buf, unsigned int *colors, > + unsigned int num_colors, unsigned int *num_parsed) Is this function going to be re-used? If not, it wants to be __init. If so, I wonder where the input string is going to come from ... Also "num_colors" looks to be misnamed - doesn't this specify an upper bound only? > +{ > + const char *s = buf; > + > + if ( !colors || !num_colors ) > + return -EINVAL; Why do you check colors but not ... > + *num_parsed = 0; ... num_parsed? I think internal functions don't need such NULL checks. > + while ( *s != '\0' ) > + { > + if ( *s != ',' ) Hmm, this way you also accept leading/trailing commas as well as multiple consecutive ones. Elsewhere we're more strict. > @@ -70,12 +150,85 @@ void __init llc_coloring_init(void) > arch_llc_coloring_init(); > } > > +void domain_llc_coloring_free(struct domain *d) > +{ > + xfree(__va(__pa(d->llc_colors))); This __va(__pa()) trick deserves a comment, I think. > +} > + > void domain_dump_llc_colors(const struct domain *d) > { > printk("Domain %pd has %u LLC colors: ", d, d->num_llc_colors); > print_colors(d->llc_colors, d->num_llc_colors); > } > > +static unsigned int *alloc_colors(unsigned int num_colors) > +{ > + unsigned int *colors; > + > + if ( num_colors > max_nr_colors ) > + return NULL; Shouldn't check_colors() have made sure of this? If so, convert to ASSERT()? > + colors = xmalloc_array(unsigned int, num_colors); > + if ( !colors ) > + return NULL; These last two lines are redundant with ... > + return colors; ... this one. Question then is whether this is useful at all as a separate helper function. > +} > + > +static int domain_check_colors(const struct domain *d) > +{ > + if ( !d->num_llc_colors ) > + { > + printk(XENLOG_ERR "No LLC color config found for %pd\n", d); > + return -ENODATA; > + } > + else if ( !check_colors(d->llc_colors, d->num_llc_colors) ) I generally recommend against use of "else" in cases like this one. > + { > + printk(XENLOG_ERR "Bad LLC color config for %pd\n", d); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static int domain_set_default_colors(struct domain *d) > +{ > + unsigned int *colors = alloc_colors(max_nr_colors); > + unsigned int i; > + > + if ( !colors ) > + return -ENOMEM; > + > + printk(XENLOG_WARNING > + "LLC color config not found for %pd, using default\n", d); Leaving open what the default(s) is/are. Judging from ... > + for ( i = 0; i < max_nr_colors; i++ ) > + colors[i] = i; ... this it's simply "all colors". Then perhaps have the message also say so? > + 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); > + > + colors = alloc_colors(dom0_num_colors); > + if ( !colors ) > + return -ENOMEM; > + > + memcpy(colors, dom0_colors, sizeof(unsigned int) * dom0_num_colors); sizeof(*colors) or some such please. Plus a check that colors and dom0_colors are actually of the same type. Alternatively, how about making dom0_colors[] __ro_after_init? Is this too much of a waste? Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:32:14 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:32:14 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674420.1049297 (Exim 4.92) (envelope-from ) id 1rVXAr-0004Tc-4r; Thu, 01 Feb 2024 13:32:13 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674420.1049297; Thu, 01 Feb 2024 13:32: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 1rVXAr-0004TV-1W; Thu, 01 Feb 2024 13:32:13 +0000 Received: by outflank-mailman (input) for mailman id 674420; Thu, 01 Feb 2024 13:32: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 1rVXAq-0004Sp-Ew for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:32:12 +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 4d5c9c05-c106-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 14:32:10 +0100 (CET) Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a363961b96aso116845466b.3 for ; Thu, 01 Feb 2024 05:32: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 ty8-20020a170907c70800b00a353d1a19a9sm6117061ejc.191.2024.02.01.05.32.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 05:32: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: 4d5c9c05-c106-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706794330; x=1707399130; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=HSbL1ahC/OCghSLFI8J5zchzx+wbFweFqGoB6NFWkk0=; b=Ljpcmgj0HULTlfTyQ9R7Ih1X+PniRoaty+B++Yx+LI51aO6024FMTqKoSrInPRokTt kjdwW0BfWxuOB0i5nzV3jLF2GR6ZePD7PV56YiZLwRGVCEQrzHdDpnhCKVLqSPLqUavp 4oEmgxRweQTatxB7ZtiHl6mDj9WD0rLaTTzTnhTFcv0RatWDl6rUJLNxBlxRL3j15voc CKsiXH9kKuMVTQXdFFCnIQ6A8A6pu4FVlq96BM2tyJTx5BUvHrASSb54MCyXQeCzEy5I lKx43WGf5+GCYKgm96E6B8QLie6VfQomeqtjI44Z5BJGsEMj4GJoihu5kQBh2WLdL4FG TnKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706794330; x=1707399130; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HSbL1ahC/OCghSLFI8J5zchzx+wbFweFqGoB6NFWkk0=; b=FxUelkZ8egffsAkwpS8UcrYhtzZE3aXgIaS7tNim1govlgQkPnDNPtq/Memr+WRblb KJXr78YBvySGxLd8qEbNEa8uKkakAMxCW5LutUeEqJWrQgdHyAtwEhILjCnkL697gEzo 5wuCik62CboY0Zu7yVTNb0iRN8HncXCz2y8CynDJSGFi1lZlZbDTQVjJW2nhnWgoXwJp vh/evaZJaLmGDcmmSh5oFTltf5r73RYPh59EHVoiWBqpDbPbZCqSm2cLOsB1ZTgEzpE5 FlxpQCR390kV6tLcyQ1S0A/b08UUlZ/TSB0sZu1QNJ04ktn74uFPuJg5s8aJzDw3RaSE 1dyQ== X-Gm-Message-State: AOJu0YxAQ1KCY6tQtgasi3RMSVnar39CBHbKdgndpnuMi3arabTUDi5v /o+I8XeS+KfSR+TX1vrj4fRxzDS2daxVKfzkwLLelEB2rc5v/pMHFYGSJzl6nA== X-Google-Smtp-Source: AGHT+IEYlUuzvJFTDcaly8PjGRwlnOCmuFO1sYrOi/L1Dkaf3e95uQwbB+VihWBnrzyKOJ2wIBdaLQ== X-Received: by 2002:a17:906:c78b:b0:a33:1d7d:912f with SMTP id cw11-20020a170906c78b00b00a331d7d912fmr4014306ejb.8.1706794330225; Thu, 01 Feb 2024 05:32:10 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUXS1Fst4W2B5k+letico01XszACO8b/dq/eXMxAKOsAT/y74D9/t8FH9vpIIg9fhsm6aUhaYGsfyFUcqdE0mZ5Z3gdSPIqIE+8px36tptwSre2bO7nByoFXGPHc5er9fBy4t3Bu7vy26112MA+XewsIM0NTjW7J1/LcojUbRYoLJ2fSLOhN14JCaB9yuZvQufBYG96/mzei2KN2q21ehXCpViGMMMG/wRew2Amr89uPNVQ/x5hdfLinkAyg18ixRbcArcBMc2pKNdhCCqdS1qWW5OswPWE Message-ID: <5e309560-51a8-4b9a-962d-819470375f62@suse.com> Date: Thu, 1 Feb 2024 14:32:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 01/15] xen/common: add cache coloring common code Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-2-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:17, Carlo Nonato wrote: > --- a/xen/include/xen/sched.h > +++ b/xen/include/xen/sched.h > @@ -626,6 +626,11 @@ struct domain > > /* Holding CDF_* constant. Internal flags for domain creation. */ > unsigned int cdf; > + > +#ifdef CONFIG_LLC_COLORING > + unsigned const int *llc_colors; > + unsigned int num_llc_colors; > +#endif > }; Btw, at this point flipping the order of the two fields will be more efficient for 64-bit architectures (consuming a padding hole rather than adding yet another one). Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:32:49 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:32:49 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674423.1049306 (Exim 4.92) (envelope-from ) id 1rVXBR-0004yD-CN; Thu, 01 Feb 2024 13:32:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674423.1049306; Thu, 01 Feb 2024 13:32: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 1rVXBR-0004y6-9l; Thu, 01 Feb 2024 13:32:49 +0000 Received: by outflank-mailman (input) for mailman id 674423; Thu, 01 Feb 2024 13:32: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 1rVXBQ-0004k9-06 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:32:48 +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 62b1199c-c106-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:32:46 +0100 (CET) Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-33b14702adaso414497f8f.3 for ; Thu, 01 Feb 2024 05:32: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: 62b1199c-c106-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; t=1706794366; x=1707399166; 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=q1N1WhUa+zlUda6ded9+L5IGCZd1kPELbcb28F33NvM=; b=HMXydHZ2OiqMc/911YWyxB09s8pcu5ffQElF66mzj4TPpSp3s821tvkSUPI1W+buHV HldUL4wNmjoLMQCWuIVQb1ERazG39qAX3frvnqIxP+IXk+0o5wARLWi8fr9Nvkp7VnuY VlEaBYbPsWgpZBgWhczTE+M0iS/0OE9Np/gVERMPKdT8we0m0d26qHVT5FKINhBVnsNp VFrk+DXtGp7tZENpGDFSkl/0zYZT86kpi3Jfk6tjS0/pWyrpUgsxICCJmiWgxHG9aupY S9TxkJ3m7Od7QKbvY52wAq3n2caaB8JwCFKtfXVmM/3Qc+PFFMo0mDATJ8aFKXQ46GuI Gh4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706794366; x=1707399166; 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=q1N1WhUa+zlUda6ded9+L5IGCZd1kPELbcb28F33NvM=; b=gVCazNyqwIM74GLQPrxHzdHNIuAtaicuO87DHI/UFpuQ46Gdl5uh/cHdPOsaTKFkzP 3U9IZ9UJjsuibbOlRsWBHQLvwfg29M8z9KsFtc0axpdIpSdlcJx1uByNGy+3o1kMLgUB wWo8+bAU9thrSFVwbYw0bTvG/lN7s8zDtXW2mhmDQEVm7D5c7pI1VAxqu2FfYBWANoro Kl9qfNXNeXVOXLlfscArymYoYTpyv6x0FdZAWVkK8F7AtAjA+MQC4ENNCkN9EWoTVE39 p/SSGQ3QgK76vCsNGqzn6JQVxki2BS8LjzAxhpgVA7OJycboFX0Mhrvgi/AVyspvOt4n ueGQ== X-Gm-Message-State: AOJu0Yy0JPCT9vbbdZExBmv+H55dUXyG2I5EI31wBepyGcJHSWGYSWhp EMU+O7Vp18qzEGl1Q8Cr72rtlkKsJvWmuFQ9YW2/rgG+QwQFheAsTMBY5J9+UEKVquCONibuZqQ 4hDzUk9i+CIuNeTDf5ONAhn9ZtNI= X-Google-Smtp-Source: AGHT+IHy2GjZWx2D3UbxOtDX7JOyRUDWbtychyj3EAprrf88Hk0njswWMcO7Dgc0SCwAMARJcQsFgQOWPsqvhYV2ejQ= X-Received: by 2002:a5d:4b04:0:b0:33b:e5f:edec with SMTP id v4-20020a5d4b04000000b0033b0e5fedecmr2584518wrq.16.1706794365798; Thu, 01 Feb 2024 05:32:45 -0800 (PST) MIME-Version: 1.0 References: <5d6c927e-7d7c-5754-e7eb-65d1e70f6222@suse.com> <7cce89f4-962e-bfbe-7d30-18fea7515bed@suse.com> In-Reply-To: <7cce89f4-962e-bfbe-7d30-18fea7515bed@suse.com> From: George Dunlap Date: Thu, 1 Feb 2024 13:32:34 +0000 Message-ID: Subject: Re: [PATCH v2 2/2] x86/p2m: aid the compiler in folding p2m_is_...() To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: multipart/alternative; boundary="000000000000e0ccbb0610520702" --000000000000e0ccbb0610520702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 23, 2022 at 12:54=E2=80=AFPM Jan Beulich wr= ote: > By using | instead of || or (in the negated form) && chances increase > for the compiler to recognize that both predicates can actually be > folded into an expression requiring just a single branch (via OR-ing > together the respective P2M_*_TYPES constants). > > Signed-off-by: Jan Beulich > Sorry for the delay. Git complains that this patch is malformed: error: `git apply --index`: error: corrupt patch at line 28 Similar complaint from patchew when it was posted: https://patchew.org/Xen/5d6c927e-7d7c-5754-e7eb-65d1e70f6222@suse.com/ -George --000000000000e0ccbb0610520702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jun 23, 2022 at 12:54=E2=80= =AFPM Jan Beulich <jbeulich@suse.co= m> wrote:
By using | instead of || or (in the negated form) && chances incre= ase
for the compiler to recognize that both predicates can actually be
folded into an expression requiring just a single branch (via OR-ing
together the respective P2M_*_TYPES constants).

Signed-off-by: Jan Beulich <jbeulich@suse.com>

S= orry for the delay.=C2=A0 Git complains that this patch is malformed:
=

error: `git apply --index`: error: corrupt patch a= t line 28

Similar complaint from patchew when = it was posted:


=C2=A0-George=C2=A0
=C2=A0
--000000000000e0ccbb0610520702-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:35:45 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:35:45 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674429.1049317 (Exim 4.92) (envelope-from ) id 1rVXEE-0005bB-Q6; Thu, 01 Feb 2024 13:35:42 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674429.1049317; Thu, 01 Feb 2024 13:35: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 1rVXEE-0005b4-ND; Thu, 01 Feb 2024 13:35:42 +0000 Received: by outflank-mailman (input) for mailman id 674429; Thu, 01 Feb 2024 13:35:41 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVXED-0005ay-7r for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:35:41 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVXE8-00018T-5A; Thu, 01 Feb 2024 13:35:36 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rVXE7-0005nq-TT; Thu, 01 Feb 2024 13:35: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=6zsy4WakuTn74XC7bvekR33avbJIFGCKsBaSH8B/Nkk=; b=vgnHXgXOOytksbrFMm8skNetQ8 C/J63cs7CWC1BoSur++uWVpGw1Ck3fT1PlFMG4PkNTlXR3vMVlHktDKAP07AKz8g3ZHyI+YK7NtAV eWzTJjP6tLHtpdyGnLUVyCj6ZgeuWmc1Hi6r3qVecgrb3z2Xz1bEqnpsRDA1FPi1UPUw=; Message-ID: <12b2d25a-ff80-45d8-ad3e-fca6684508df@xen.org> Date: Thu, 1 Feb 2024 13:35:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 04/15] xen/arm: add Dom0 cache coloring support Content-Language: en-GB To: Jan Beulich , Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-5-carlo.nonato@minervasys.tech> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 01/02/2024 13:30, Jan Beulich wrote: > On 29.01.2024 18:18, Carlo Nonato wrote: >> 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. > > What implications does this have? > >> --- 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 options is available only when >> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available >> +colors are used. > > Even Arm already has a "dom0=" option. Is there a particular reason why > this doesn't become a new sub-option there? > > As to meaning: With just a single , that's still a color value > then (and not a count of colors)? Wouldn't it make sense to have a > simpler variant available where you just say how many, and a suitable > set/range is then picked? > > Finally a nit: "This option is ...". > >> @@ -2188,10 +2190,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); > > As for the earlier patch, I find panic()ing here dubious. You can continue > quite fine, with a warning and perhaps again tainting the system. There are arguments for both approach. I agree that you can continue but technically this is not the configuration you asked. Someone may not notice the tainting until it is too late (read they have done investigation). Bear in mind that the user for cache coloring will be in very specialized environment. So if you can't enable cache coloring in production, then something really wrong has happened and continue to boot is probably not right. This matches the approach for Arm we have been using since the beginning. And I will strongly argue to continue this way. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:39:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:39:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674433.1049326 (Exim 4.92) (envelope-from ) id 1rVXI5-0007Kj-CJ; Thu, 01 Feb 2024 13:39:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674433.1049326; Thu, 01 Feb 2024 13:39: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 1rVXI5-0007K2-9F; Thu, 01 Feb 2024 13:39:41 +0000 Received: by outflank-mailman (input) for mailman id 674433; Thu, 01 Feb 2024 13: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 1rVXI3-0007If-8T for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:39:39 +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 5807a138-c107-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:39:38 +0100 (CET) Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-55f2b0c5ae9so1187399a12.2 for ; Thu, 01 Feb 2024 05:39: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 e6-20020a50ec86000000b0055fbc52457fsm415569edr.30.2024.02.01.05.39.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 05:39: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: 5807a138-c107-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706794778; x=1707399578; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=XxXKa9rZUl8KpqDrwZu8AgUKl5L3iDiVhgOfVsooojw=; b=elFg1tMGExKhVZIY52162xXonEH9dbsp0d3WhHbDc+/zqsGP1jIeyXg6vHfK8B9jio ivD+aICmCPXzhImNBUYujlH/6VACqxbFDuWnbMxnjReJAWMkB5oxWFsRMftWj49WsgnI 1keqCfSE5sqiRBL4/cS47NCMXsP7PM4VRYv7jpIzCzTazeYhnrvNGoC2WX0ABbBcSl5h nvqUk9y/RNV2/YETIyZNdzFScwTudUz6Ou0/2DUapx74g5JLEu2sLPP66mxDMmv0ChCz pgT9ahzCqZs09c7T1+S3b+4qmuV2TGooczIOe19312sycIGwKGm4wYk8LCI8zDtvk2gu iY7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706794778; x=1707399578; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=XxXKa9rZUl8KpqDrwZu8AgUKl5L3iDiVhgOfVsooojw=; b=q00IMasrLI1x/OwM5f/os7Yp27NvpAkHiCa3UUfCd3/D53skJTirvFMtmLWjJxF2n/ I3Q7+NFri+z5W0Q4sPfQXo5MmJCCUD/CHI6q39Ean8+P4HdQtQ77SxHkbjn0VwtBgBAj yTouZlWnxw4L3qbpVQysJcdDEjnyW3dhIVsPrFXNFyqP8RmjRL3J7s5dKq6JM4+v8SgP gwUep5Uoi888zxaCcNOY4tz3p01OODK6tCLPDSl0BEdh+9C2jnMQsWxdHu1YV7RFIZ3E VGLvCFQs9Rrsc348y0ivk30D+NaoEM7RducVx0GOeflZEQ9CsYWuWkVDFIjTjEMBDDUp vzag== X-Gm-Message-State: AOJu0Yx2ZSqhVmtMXq2AlLSlieBj91EEdUzQ4qBZImOAoy+oZBsACxlx laE/xPY+UAGVrD8BWmMjdpZhqh85jbBiDMdS/vsNxNMSQy+QfloV2jNLqxeORQ== X-Google-Smtp-Source: AGHT+IGECh5aNBsOigEpT3v2t8BrUbtPJKPmkXoF3D02N6X817HjuwqShtttIA0jixaptbd4Ahmznw== X-Received: by 2002:aa7:d386:0:b0:55f:64ca:5a6e with SMTP id x6-20020aa7d386000000b0055f64ca5a6emr3120308edq.12.1706794777653; Thu, 01 Feb 2024 05:39:37 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVngAvbmO7RP9zivsg+O4UQGLFVvLk02FwXI2a/EG1PyOocMEwhB2trjeybxR1RWKQ5RUqqCVq0B4T+x5z9druc/i4xRXubtgBdwbI4k5El1fawvvNPN+lzrRZvr68WM0h/MYbMmBrsdYY3JtMbyAngNL184PljLmCyJ5DogdG2XcYC+YzlRz1Yu4QjhrnGYnc7iPBGqEpTBbwNfzyeQ+c2G4vHDzxWVTxVYm4YXDeGEAoVvju/shVdxOJS0fuigYGMJbTWSorfPKB2jyy5VaFoD4KXTw/3034xLI4njBax9l8xawNsT+bILoQPTFQ1Br/PkrHUH/rikyV1oeilbfOJ234PjBwHkCqTO3wpMPV1U4aRGJf0Rnzmm7B2pHe0+B9KYX1FB678fcSxFWLDknz4 Message-ID: <02b2905d-cc83-4c39-bc29-2ac8351bfc37@suse.com> Date: Thu, 1 Feb 2024 14:39:35 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 04/15] xen/arm: add Dom0 cache coloring support Content-Language: en-US To: Julien Grall Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Marco Solieri , xen-devel@lists.xenproject.org, Carlo Nonato References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-5-carlo.nonato@minervasys.tech> <12b2d25a-ff80-45d8-ad3e-fca6684508df@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: <12b2d25a-ff80-45d8-ad3e-fca6684508df@xen.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01.02.2024 14:35, Julien Grall wrote: > Hi Jan, > > On 01/02/2024 13:30, Jan Beulich wrote: >> On 29.01.2024 18:18, Carlo Nonato wrote: >>> 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. >> >> What implications does this have? >> >>> --- 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 options is available only when >>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available >>> +colors are used. >> >> Even Arm already has a "dom0=" option. Is there a particular reason why >> this doesn't become a new sub-option there? >> >> As to meaning: With just a single , that's still a color value >> then (and not a count of colors)? Wouldn't it make sense to have a >> simpler variant available where you just say how many, and a suitable >> set/range is then picked? >> >> Finally a nit: "This option is ...". >> >>> @@ -2188,10 +2190,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); >> >> As for the earlier patch, I find panic()ing here dubious. You can continue >> quite fine, with a warning and perhaps again tainting the system. > There are arguments for both approach. In which case - perhaps allow for both? With a Kconfig-established default and a command line option to override? > I agree that you can continue but > technically this is not the configuration you asked. Someone may not > notice the tainting until it is too late (read they have done > investigation). > > Bear in mind that the user for cache coloring will be in very > specialized environment. s/will/may/ I suppose. People may enable the option without being in any specialized environment. > So if you can't enable cache coloring in > production, then something really wrong has happened and continue to > boot is probably not right. > > This matches the approach for Arm we have been using since the > beginning. And I will strongly argue to continue this way. I'm okay with this, and here (for Arm-specific code) it may even be okay to do so without further justification. But in the earlier patch where common code is affected, I'll insist on at least justifying this behavior. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:48:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:48:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674440.1049336 (Exim 4.92) (envelope-from ) id 1rVXQs-0001GR-69; Thu, 01 Feb 2024 13:48:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674440.1049336; Thu, 01 Feb 2024 13:48: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 1rVXQs-0001GK-3Q; Thu, 01 Feb 2024 13:48:46 +0000 Received: by outflank-mailman (input) for mailman id 674440; Thu, 01 Feb 2024 13:48: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 1rVXQr-0001GE-C0 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:48:45 +0000 Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [2a00:1450:4864:20::42d]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9d82452d-c108-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:48:44 +0100 (CET) Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-337cc8e72f5so586336f8f.1 for ; Thu, 01 Feb 2024 05:48: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: 9d82452d-c108-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; t=1706795324; x=1707400124; 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=uAGJ40Mi5YAKkJYTVBw8bZ5DQVfGYXwY1pM2JcXYAro=; b=ahqFhiZepKwvOq6s3o0cYYqp0wP7EtlJ4xfGJNiBSaTrhx1XsrN26inzDOedg2scMC pWDCN1S5J5YH9X5YXWDOli+yfoKM5+jKtzIpF4H8SufG2WrUVqXhafp8MV9bS2FzwtVr 3LEqYGMbjnOkAOj8TV+PgK9q1f0YK/KNEUYucnk4QAqelUpxPLjDHmPrL34FsifTD1S7 DY9ohoAX1E9MBEXr4e+RM2KQnXAJZ9PTzOmooJHWmWvXGkRy2TMiVff3LZNEQiqBnZGE rM9W+qpzZGyZFE7IrWtLJbVsWEkEcUr5iajnV1ebp6OT5qaxCH/WVj1b2Z8oUeGkVxB6 HM9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706795324; x=1707400124; 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=uAGJ40Mi5YAKkJYTVBw8bZ5DQVfGYXwY1pM2JcXYAro=; b=WEnn/qqrTFOjGbVbnqa56O16Hr3VtocvUpMxhrVFbdIkMe5p8DU+sdH5QWcNzZihzt 5pQuAi2vlNDcUiTnljsKGMjsQb54/UbdXPN/XPFRe5Faao6oQsntqRj1yAPQZdbMGTcT D7UAm2MzVKE0/lPKG1kem0Ghwx3JOdLU2WL7jMhHQaItmhfwrCr4uAVk+B1lO+5vyDyh t8PZLlhZJPktVJrDNS7uGtmsxjnKvkEj5otG7wH5YMPstGXLiFvAXn/ryLDm2DnjAmsa TXTAMWBkOaFLosTTdC6+eHM6FX33F4cX/JNX/MmhfU5u2PjHNW99GgspXgz7GoY2BoK+ my4g== X-Gm-Message-State: AOJu0Yy6NJqUwcJZgd9sIDtomtYgH+V+ZF0hILGZTa9ZjJc+jAiyVjfg ftQ88U+WYHvlq5o5O47/uyxX+LPxxMNalu+InJzGI348f6SWqA7IuHdNVjTUM9dYRVAlvT2DKJn awNyoen0/ivrWTN6O18JIaCQerD4= X-Google-Smtp-Source: AGHT+IE7tozFHaLnynQdgdJw3y9iEQ0VpntF/6OAUIFHKYfZhEIPGYvIBgrm0kz22Dc/kTDHdCp7PYd5aB4dp8NUV+U= X-Received: by 2002:adf:ee10:0:b0:33a:ecd6:1c71 with SMTP id y16-20020adfee10000000b0033aecd61c71mr1714660wrn.56.1706795323475; Thu, 01 Feb 2024 05:48:43 -0800 (PST) MIME-Version: 1.0 References: <0c61e460-122c-6486-00b7-22a9a24ee1fc@suse.com> In-Reply-To: <0c61e460-122c-6486-00b7-22a9a24ee1fc@suse.com> From: George Dunlap Date: Thu, 1 Feb 2024 13:48:32 +0000 Message-ID: Subject: Re: [PATCH v2 1/3] x86/PoD: simplify / improve p2m_pod_cache_add() To: Jan Beulich Cc: "xen-devel@lists.xenproject.org" , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: multipart/alternative; boundary="000000000000f5cef90610524009" --000000000000f5cef90610524009 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 4, 2022 at 9:48=E2=80=AFAM Jan Beulich wrot= e: > Avoid recurring MFN -> page or page -> MFN translations. Drop the pretty > pointless local variable "p". Make sure the MFN logged in a debugging > error message is actually the offending one. Return negative errno > values rather than -1 (presently no caller really cares, but imo this > should change). Adjust style. > > Signed-off-by: Jan Beulich > Sorry, not sure how I managed to miss this: Reviewed-by: George Dunlap --000000000000f5cef90610524009 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000f5cef90610524009-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:51:37 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:51:37 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674444.1049347 (Exim 4.92) (envelope-from ) id 1rVXTb-0003TA-Jf; Thu, 01 Feb 2024 13:51:35 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674444.1049347; Thu, 01 Feb 2024 13:51: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 1rVXTb-0003T3-H0; Thu, 01 Feb 2024 13:51:35 +0000 Received: by outflank-mailman (input) for mailman id 674444; Thu, 01 Feb 2024 13:51: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 1rVXTa-0003Sx-M0 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:51:34 +0000 Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [2a00:1450:4864:20::433]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 025962d3-c109-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:51:33 +0100 (CET) Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-33b1a51743fso255695f8f.0 for ; Thu, 01 Feb 2024 05:51: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 o2-20020a5d4a82000000b0033b1277e95dsm2119858wrq.77.2024.02.01.05.51.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 05:51: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: 025962d3-c109-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706795493; x=1707400293; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=8RRdQKASc3af7mpTARYqUcV+0lPpVTBJtM4WGMrlCRw=; b=AQAMHaPpRg691kwz/SeL4DcMupVqnsJk3jhtovx3ZR1GsqpFv35GZw0Mku4gbmOI9b wWSNWbk4N376x1JslwLhA7n8MdJOx9Z8vMhqQumJReGMijTRKVOgntv5LM8VNYybNbQ6 XcKbcotk9G5k7YZlMf5zK3Cxp2kqKM7ZMy+ZS60fsz6Zz8mbrNefy5P/lrXn+HE2a0L4 hJNreWQHuRzSWeKIuw9aSWdfQh4OCM9RlI+gurE2ImKBU0proy49C7Q2kulAbiyE5JEw Wh0xCCqVWaqowtyDUBdHT9vt98cUbZocRRr86Q90EwT8OVe3H877zIuMiBGCE4mAhAQi B9Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706795493; x=1707400293; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8RRdQKASc3af7mpTARYqUcV+0lPpVTBJtM4WGMrlCRw=; b=dxNVEyA9kD66itUxye3UrO1LtvAzwVbpZvSRDkj0ksxpKIHznYhaa4CHuMdXFm3lir +45Pt+ugvlWC0Dtq/oVboRLj0S2d1xoTvLmP9bc6nJnLI4XxdyYnkXyiZsBE4K+faV6K 6oTTeBBMO6VdOB9NPErRPC3niiwUDxcR+/ypbIK3VpahR+QDHFyDjzrml1F/+Bonot7N bpgyRUJrUInOG+1HP+y5Kj2DSF01MK3aLg3mNdDpcMUMvxMUZsSdsAIxR6EfJGjHLtTl xetarOIaJd7QKIayr7dEiaXb9FR4F2R60tq3XBt6dM6LzomImry8N0TVb832Nfz40dI3 qTPQ== X-Gm-Message-State: AOJu0Yzs+2enboizNcjPLTw+0zpS+X5ACd9y2iOZwI5Qt+/1N+AHVyES Yhmyp7mUCoGykF/mW4SLBMpQqC9Q27PwwSla8L90DtNdBXwZlNDznZw/1tuPeQ== X-Google-Smtp-Source: AGHT+IFMBy8UxQLDea4mgrUx/zzQwIOassxiv2dP8qnvvs6//4Bn0T41OedMDEPWMSkZT6UI6Pd3Fg== X-Received: by 2002:adf:ce8b:0:b0:33a:eae4:aaf7 with SMTP id r11-20020adfce8b000000b0033aeae4aaf7mr3489557wrn.48.1706795492933; Thu, 01 Feb 2024 05:51:32 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVxHvl2mTcAPoZFlqoBOxEKsYLkudUEhv4D2bXChYhJXFEbGOOqDIEcPN/gcwZMR/HfIBcRen8SPC7QV2XjKCQuwK4/fPf+KMW7Uz7xxMW2Fv7CSHUbB5CxRSYhmsDzsGUzqYo6MiSeeglG3M/XEKvldWp8IPzaaG4vsq6bwzZkBcGZI2As2YzcjlLOv4NHyFg9pSjOOBj5RKrC5WseG7andnq9bCeGxHkNjbVSy6bz0q6ok8gBVv7R8bpbhEmF57pJvhfYKMZcgAdPyg+MdRcJdHdN00RN Message-ID: <49827753-14f1-42cc-8791-27c5400e6e50@suse.com> Date: Thu, 1 Feb 2024 14:51:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 05/15] xen: extend domctl interface for cache coloring Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-6-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > @@ -858,6 +859,16 @@ 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 ) > + break; With "ret" still being 0, this amounts to "successfully ignored". Ought to be -EOPNOTSUPP, I guess. > + ret = domain_set_llc_colors_domctl(d, &op->u.set_llc_colors); > + if ( ret == -EEXIST ) > + printk(XENLOG_ERR > + "Can't set LLC colors on an already created domain\n"); If at all a dprintk(). But personally I think even that's too much - we don't do so elsewhere, I don't think. > --- 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 > @@ -229,6 +230,30 @@ int __init dom0_set_llc_colors(struct domain *d) > return domain_check_colors(d); > } > > +int domain_set_llc_colors_domctl(struct domain *d, > + const struct xen_domctl_set_llc_colors *config) What purpose has the "domctl" in the function name? > +{ > + unsigned int *colors; > + > + if ( d->num_llc_colors ) > + return -EEXIST; > + > + if ( !config->num_llc_colors ) > + return domain_set_default_colors(d); > + > + colors = alloc_colors(config->num_llc_colors); > + if ( !colors ) > + return -ENOMEM; Hmm, I see here you call the function without first having bounds checked the input. But in case of too big a value, -ENOMEM is inappropriate, so such a check wants adding up front anyway. > + if ( copy_from_guest(colors, config->llc_colors, config->num_llc_colors) ) > + return -EFAULT; There again wants to be a check that the pointed to values are the same, or at least of the same size. Else you'd need to do element-wise copy. > + d->llc_colors = colors; > + d->num_llc_colors = config->num_llc_colors; > + > + return domain_check_colors(d); And if this fails, you leave the domain with the bad settings? Shouldn't you check and only then store pointer and count? > --- 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 padding; I see you've added padding, but: You don't check it to be zero. Plus the overwhelming majority of padding fields is named "pad". Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:55:13 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:55:13 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674448.1049357 (Exim 4.92) (envelope-from ) id 1rVXX3-00043U-3Q; Thu, 01 Feb 2024 13:55:09 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674448.1049357; Thu, 01 Feb 2024 13: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 1rVXX2-00043N-Ve; Thu, 01 Feb 2024 13:55:08 +0000 Received: by outflank-mailman (input) for mailman id 674448; Thu, 01 Feb 2024 13:55:07 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVXX1-00043G-NL for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:55:07 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVXWw-0001UW-OC; Thu, 01 Feb 2024 13:55:02 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rVXWw-0006WY-HF; Thu, 01 Feb 2024 13:55: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=BWz9L10Z3/J3KrmaAbRIqLHSINybu8RaJ2IT/zQ6ddg=; b=PkLahu2Zq8kY+vanGWH6Capr1r zrGyRuZoltZ2UmqTB6FDokYyA76pBHhmDi8awyaTnsk34SQWStxN1rvky4ih0BiDhHjAmOleymGvh mk8tGyXJlio0HuvxKS+LTihpqa//nnkbaLtL9nkHou53hfrQncrVJT0BduF5ntAvTwGI=; Message-ID: <4d913f15-f2e7-412d-a3c2-727c83df7ec1@xen.org> Date: Thu, 1 Feb 2024 13:55:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 04/15] xen/arm: add Dom0 cache coloring support Content-Language: en-GB To: Jan Beulich Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Marco Solieri , xen-devel@lists.xenproject.org, Carlo Nonato References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-5-carlo.nonato@minervasys.tech> <12b2d25a-ff80-45d8-ad3e-fca6684508df@xen.org> <02b2905d-cc83-4c39-bc29-2ac8351bfc37@suse.com> From: Julien Grall In-Reply-To: <02b2905d-cc83-4c39-bc29-2ac8351bfc37@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, On 01/02/2024 13:39, Jan Beulich wrote: > On 01.02.2024 14:35, Julien Grall wrote: >> Hi Jan, >> >> On 01/02/2024 13:30, Jan Beulich wrote: >>> On 29.01.2024 18:18, Carlo Nonato wrote: >>>> 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. >>> >>> What implications does this have? >>> >>>> --- 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 options is available only when >>>> +`CONFIG_LLC_COLORING` is enabled. If the parameter is not set, all available >>>> +colors are used. >>> >>> Even Arm already has a "dom0=" option. Is there a particular reason why >>> this doesn't become a new sub-option there? >>> >>> As to meaning: With just a single , that's still a color value >>> then (and not a count of colors)? Wouldn't it make sense to have a >>> simpler variant available where you just say how many, and a suitable >>> set/range is then picked? >>> >>> Finally a nit: "This option is ...". >>> >>>> @@ -2188,10 +2190,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); >>> >>> As for the earlier patch, I find panic()ing here dubious. You can continue >>> quite fine, with a warning and perhaps again tainting the system. >> There are arguments for both approach. > > In which case - perhaps allow for both? With a Kconfig-established > default and a command line option to override? Perhaps. But this is a separate discussion from this series. What Carlo has been doing match the surrounding code on Arm. > >> I agree that you can continue but >> technically this is not the configuration you asked. Someone may not >> notice the tainting until it is too late (read they have done >> investigation). >> >> Bear in mind that the user for cache coloring will be in very >> specialized environment. > > s/will/may/ I suppose. People may enable the option without being in > any specialized environment. Sure. But again, why would you want to boot with a half broken configuration? In a lot of cases, you are not making a favor to the admin to continue to boot. It is easy to say there is a warning in the logs, but this can often be overlooked and difficult to diagnostic afterwards. For instance, if you think about cache coloring the issue would be latency. I don't think a lambda users will be able to easily figure out that their configuration was wrong. Futhermore, when you operate at scale, I feel it is better to have an early boot crash rather than allowing the system to boot (parsing the logs is feasible but IMO risky as they are not stable). > >> So if you can't enable cache coloring in >> production, then something really wrong has happened and continue to >> boot is probably not right. >> >> This matches the approach for Arm we have been using since the >> beginning. And I will strongly argue to continue this way. > > I'm okay with this, and here (for Arm-specific code) it may even be okay > to do so without further justification. But in the earlier patch where > common code is affected, I'll insist on at least justifying this behavior. See above for a justification. If someone asks for cache coloring, then you most likely don't want to continue without cache coloring. If you dislike the panic() in common code, then we can simply modify the function to return an error and move the panic() in the Arm code. This is not my preference, but I am under the impression that we both have very diverging view how to handle boot error and it will be hard to reconcile them (at least in this series, this can be done afterwards if somone fancy to write a series matching what you proposed above). So this would be the second best option for me. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Feb 01 13:57:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 13:57:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674453.1049367 (Exim 4.92) (envelope-from ) id 1rVXZi-0004ki-JF; Thu, 01 Feb 2024 13:57:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674453.1049367; Thu, 01 Feb 2024 13:57: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 1rVXZi-0004kb-Fr; Thu, 01 Feb 2024 13:57:54 +0000 Received: by outflank-mailman (input) for mailman id 674453; Thu, 01 Feb 2024 13:57: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 1rVXZg-0004kP-Lv for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 13:57:52 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on20601.outbound.protection.outlook.com [2a01:111:f403:2612::601]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id e3791333-c109-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 14:57:51 +0100 (CET) Received: from AS4P191CA0024.EURP191.PROD.OUTLOOK.COM (2603:10a6:20b:5d9::18) by DU0PR08MB8114.eurprd08.prod.outlook.com (2603:10a6:10:3ea::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.24; Thu, 1 Feb 2024 13:57:42 +0000 Received: from AM3PEPF00009B9B.eurprd04.prod.outlook.com (2603:10a6:20b:5d9:cafe::7b) by AS4P191CA0024.outlook.office365.com (2603:10a6:20b:5d9::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.26 via Frontend Transport; Thu, 1 Feb 2024 13:57:42 +0000 Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM3PEPF00009B9B.mail.protection.outlook.com (10.167.16.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.19 via Frontend Transport; Thu, 1 Feb 2024 13:57:42 +0000 Received: ("Tessian outbound 67699c3f02bc:v228"); Thu, 01 Feb 2024 13:57:41 +0000 Received: from 70e782ea9825.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8C0B5C65-24A4-470F-8E58-CFC52442F710.1; Thu, 01 Feb 2024 13:57:35 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 70e782ea9825.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 01 Feb 2024 13:57:35 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com (2603:10a6:10:25a::24) by AM8PR08MB6436.eurprd08.prod.outlook.com (2603:10a6:20b:365::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.34; Thu, 1 Feb 2024 13:57:32 +0000 Received: from DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::2257:5fcb:b449:fff0]) by DB9PR08MB6588.eurprd08.prod.outlook.com ([fe80::2257:5fcb:b449:fff0%7]) with mapi id 15.20.7228.029; Thu, 1 Feb 2024 13:57: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: e3791333-c109-11ee-8a43-1f161083a0e0 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=RebIadRljAgFs028uav5E26E4uUm1S5wG3Rqm5TwYCX1y3MZjhIrLu/nQFWLkN2A6zmHagK5h17lH2nIIXBFpKVqFHMGy/WyW13xabJWoKg4cg7DCstAMWl9UCFeVKYyCce8SaqPoQ1nAZQZAP3le0Sq+EX4puccLR+aHTaB9v1l50Sec4bWOw7dDhkAmg4ZCBXNacppCdO0JzPm0TqUY6X5KWT4ix1E/u9HBkYU/qbhWY8hZ+6EgrtkysJoyavMFH/5DAhAz86Dylw2T+9Rh4Qg7Mu6WqczVMnl5ZQiqc287Rs7dTioPZkQ8i5qiqrlhg++Q23GSCqz85nS4KQxVQ== 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=zPdfunecO54m0x8EuWLfnmbInPCoKzwASsxqOyKq7ZI=; b=XwE9IqFSuKf7gmRZMUv74pKtVMLmlcsbtL7Dci8Ce755cCINvl0cNu5Wmu39wUdSFBvKCNbNGa9QjwdHQPxh2GawmYZbIMSqr4aFf1DfwZquNzG0+wOgxEoAHnwvtizehKUsAR4FfddaLsxDU24mRaxn/H+zdL7tfVoUep43mnPhotwnbAKkCgc8NjeRVla02/iCN59Q+LVczULVdErNdXM5jDxQEBD3NnKQvyWUjszJ9p6T3CBzhDpS17bnuAAgKf+Z4f5K/KafttFdmhttUI+jKPGF7dkfUFYtAKUciqHpGCoR76bOVgIJw25c/RsyQel74f9cTR7IznOGTGDwVg== 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=zPdfunecO54m0x8EuWLfnmbInPCoKzwASsxqOyKq7ZI=; b=UHxWHfO2T3NRY34cQPcWSeMshqjkm+/GJ9rzvgXKmJzZj6vIFxtGvnFa6AciiiGos+pSL1N2u/2+H6XAsX2zdRfEtzAr23iO5J65AXgyPgjqb1AKESTh4ap38AL+tHdiZ3Y+XbP4aT/nY0SMXyuWfXFV3H/yPP1P0CZj8g8b2bQ= 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: 6c0886f16c02cd39 X-CR-MTA-TID: 64aa7808 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N5i957EnDgbHQNi6S7QRufRbugdrh0UnaMBiiyOsj4TdpPKpPZAsqMSRnQ6f6gMzF/C+8BWcLFaI0HD4upfqJq4GAf9W9/nH5kE3i+7bllXFaIxorKl9eQe9SfeT6Zxsz54LgxoPCSpye/095LIn+rPYgeYD8QtTeUHa2qzi5Uc3g07+nKUMONuj2RavuMR/z1NlMPAoz8twr2Y0iQtTc5bS7+qVeQW6M0wzqZpYmZnNRM2ftJaT5+gpm6gCfUhK4/CdZUEcmePIIGaWQq7o28Wmez9T+r7qaMgJx787+A/zvh//n1ahU2NrEPtzPWxKwMCUdMk47/PPwmy45kRsKw== 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=zPdfunecO54m0x8EuWLfnmbInPCoKzwASsxqOyKq7ZI=; b=YsWkx8amtRh6FupGKgyFvPxgzXwhuuuYKSvzV5s0LfARF87+cvDq/ppCZs+5TiHG71CuMe2SlGEAykkV+AOenfkaZIHl0ldllWBEldzMLRz/DYbd/NAMxxggh4oxRw2h2B90Cym2flZHu/XuelIordQ+NWpAr68BM3KXrIvlrvXSaEJU6h8ZJuYcrtVSA3bU/OGa+LEE8no90lIWsHZ6BDtFcboBbZjSYj1/BizR9jeos1enH91Be3OA2brM7SwfpCelmp67tB4seZqB/SPxJZdiP1PrTj9FyPmsRoa3rKBtTucIkdGyMFfiyW8qrOM5syprTm7pxfq7V1jokEM4Vg== 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=zPdfunecO54m0x8EuWLfnmbInPCoKzwASsxqOyKq7ZI=; b=UHxWHfO2T3NRY34cQPcWSeMshqjkm+/GJ9rzvgXKmJzZj6vIFxtGvnFa6AciiiGos+pSL1N2u/2+H6XAsX2zdRfEtzAr23iO5J65AXgyPgjqb1AKESTh4ap38AL+tHdiZ3Y+XbP4aT/nY0SMXyuWfXFV3H/yPP1P0CZj8g8b2bQ= From: Bertrand Marquis To: Jens Wiklander CC: Xen-devel , "patches@linaro.org" , Volodymyr Babchuk , Stefano Stabellini , Julien Grall , Michal Orzel , Andrew Cooper Subject: Re: [XEN PATCH v3] xen/arm: ffa: reclaim shared memory on guest destroy Thread-Topic: [XEN PATCH v3] xen/arm: ffa: reclaim shared memory on guest destroy Thread-Index: AQHaSTVKNVT0ywRTlE22Kr4Xf5r90LD1mryA Date: Thu, 1 Feb 2024 13:57:31 +0000 Message-ID: <6980D75D-544A-4A3B-906B-DC27D68A260B@arm.com> References: <20240117110618.2183977-1-jens.wiklander@linaro.org> In-Reply-To: <20240117110618.2183977-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_|AM8PR08MB6436:EE_|AM3PEPF00009B9B:EE_|DU0PR08MB8114:EE_ X-MS-Office365-Filtering-Correlation-Id: f02cef81-20ea-4208-e491-08dc232dc25e 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: Tgv5bWFUrsH84yBUGu4f4tGmbiwJmFkjgxQq7njGjtmIlJRJ5i0PGcZilKgqzZ08BcNdQDCF5m3IO04tWjM3042TZKQd6gwpFFyuiDJlO5/hRJV2aEYix2v6qmIbEkwJtbXOJwZOL7S55RxWmeVepNeCv8GiSSz7FDcLFYBSN4mm6Qq2zNTL4JNm6SpgAJCBCtHHVkeVzjevnnPCN1lx8eC4ZSMvCSBvvdhFR0b36883wZBWIZeCmcdYUG2t3I9IjaJKfIe7lfVbvcDhxumlFURguZQhpT8G6Pq9Eid/d+EehAqIAdl30mZCm0eMChlsO2iOqgMgm6InopjAAlgRPLWuiTaxqg8FFA/AdJgE2tISaEJ7Mga1MAdugEuiT1vj33AF/L84Pw6AIjb0dMV81yLhEZ0S6NSII5aqU9NtLqcsW838MS6HPNK1LMArGpCOnDYlpkc5sNiA6qg2J4i3WjFqHrK+tDUwWJStLg7udeY76XWk5fjyJVSS40BKaYhUJXgp8RWPU04FwQxptchCLll+d+E2r47tKBmLgy9l+2csM4ve2LPNbiCtpo5XFi977vCAC9j0gRHBy3XnggZUFvzZQdbu9G3PFxrIr73Gn6BpXUYKjXPWuqQpn4dAifB5MZjs5mnVATPB40aG8cn/bA== 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)(346002)(136003)(396003)(366004)(39860400002)(376002)(230922051799003)(64100799003)(1800799012)(451199024)(186009)(41300700001)(2616005)(83380400001)(36756003)(6506007)(53546011)(38070700009)(478600001)(71200400001)(122000001)(6512007)(38100700002)(6486002)(54906003)(30864003)(2906002)(66556008)(8936002)(76116006)(66476007)(66446008)(6916009)(316002)(64756008)(86362001)(66946007)(5660300002)(4326008)(33656002)(8676002)(45980500001);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: AM8PR08MB6436 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: AM3PEPF00009B9B.eurprd04.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: acc22d59-8db2-4f11-f3f5-08dc232dbc43 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5evtEcsVpog9Rq/wRscMIJeqUydbn4MHjr9z5gMRKfxtosFgfckWt07as6Vk4oYHgzgyPrbpilb8KXy0Aqp9LA6LYPre8WIgBo7y/nARKijvQuD+/o88hX2L/yU0bnMFKPbLRuucZ1Hv9OBOIvT6zR4d2RpJhFwv/G9c0RdLC0ZCGLc1YQULvmmqOqsNRxFpfwY7ka21ByVR/FSjnYLqNXfH6dN2VDh4ULbICFa1ixQ65DEhFG0zBEGuGpCrHruzjRF4+7P0bPpv/yFRGtFpeKOILj1vdbF3kiXZMNsM3b2vUZcPzmA11htAfuWYv/uPYl/+3TYgayMOLU4mqUc3GYxxZns6vYUUZzTb/KlZYoXNN4dV+QGvz6tIpng3tdAsMOlmtYTeUr702OXVjO9gpd76mRDwTmC651x0ORLsWL1i55by3qyBtX83RR1tMCH75BwXXFUUU8w7eG54A/jxxYcp1WgQ22htV+FknPhidHjnzT4TEsUSVB6C2wx6boILTNUFmEgljkfY8T0OwS17Jk3Q1i/dfZzxP8wC5f3DoKC34QfBGtGtF8QWFJrJuhJ8ud9GwyJBD1JSLA+N7XpFp9EUi2E9Y5vLqifEVKrDtsbsesHkik7Z5WMDyjq9cxcYZAmfYBdDyMa2n9B0gqIurClO3PWWJ6/Aza+YzGiMREk6Os5IHKed1C/E0J97puYlS3J6ckji2dhKs53WN8uuRyuM4EzTwYTWm1LhTkElnmP9BhtBHPF8q6+jUiZTmDqL 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)(4636009)(376002)(39860400002)(396003)(346002)(136003)(230922051799003)(186009)(1800799012)(451199024)(82310400011)(64100799003)(46966006)(40470700004)(36840700001)(83380400001)(41300700001)(47076005)(6512007)(107886003)(6506007)(336012)(2616005)(8676002)(26005)(356005)(36860700001)(4326008)(81166007)(82740400003)(5660300002)(8936002)(478600001)(54906003)(30864003)(53546011)(2906002)(70586007)(6486002)(70206006)(316002)(6862004)(33656002)(36756003)(86362001)(40460700003)(40480700001);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Feb 2024 13:57:42.0642 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f02cef81-20ea-4208-e491-08dc232dc25e 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: AM3PEPF00009B9B.eurprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB8114 Hi Jens, > On 17 Jan 2024, at 12:06, Jens Wiklander wrot= e: >=20 > When an FF-A enabled guest is destroyed it may leave behind memory > shared with SPs. This memory must be reclaimed before it's reused or an > SP may make changes to memory used by a new unrelated guest. So when the > domain is teared down add FF-A requests to reclaim all remaining shared > memory. >=20 > SPs in the secure world are notified using VM_DESTROYED that a guest has > been destroyed. An SP is supposed to relinquish all shared memory to allo= w > reclaiming the memory. The relinquish operation may need to be delayed if > the shared memory is for instance part of a DMA operation. >=20 > The domain reference counter is increased when the first FF-A shared > memory is registered and the counter is decreased again when the last > shared memory is reclaimed. If FF-A shared memory registrations remain > at the end of of ffa_domain_teardown() a timer is set to try to reclaim > the shared memory every second until the memory is reclaimed. >=20 > A few minor style fixes with a removed empty line here and an added new > line there. >=20 > Signed-off-by: Jens Wiklander > --- >=20 > v3: > - Mentioning in the commit message that there are some style fixes > - Addressing review comments > - Refactor the ffa_domain_teardown() path to let > ffa_domain_teardown_continue() do most of the work. >=20 > v2: > - Update commit message to match the new implementation > - Using a per domain bitfield to keep track of which SPs has been notifie= d > with VM_DESTROYED > - Holding a domain reference counter to keep the domain as a zombie domai= n > while there still is shared memory registrations remaining to be reclaim= ed > - Using a timer to retry reclaiming remaining shared memory registrations > --- > xen/arch/arm/tee/ffa.c | 253 +++++++++++++++++++++++++++++++++-------- > 1 file changed, 204 insertions(+), 49 deletions(-) >=20 > diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c > index 0793c1c7585d..80ebbf4f01c6 100644 > --- a/xen/arch/arm/tee/ffa.c > +++ b/xen/arch/arm/tee/ffa.c > @@ -54,6 +54,7 @@ > #include > #include > #include > +#include > #include >=20 > #include > @@ -144,6 +145,12 @@ > */ > #define FFA_MAX_SHM_COUNT 32 >=20 > +/* > + * 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 > @@ -384,11 +391,6 @@ struct ffa_ctx { > unsigned int page_count; > /* FF-A version used by the guest */ > uint32_t guest_vers; > - /* > - * Number of SPs that we have sent a VM created signal to, used in > - * ffa_domain_teardown() to know which SPs need to be signalled. > - */ > - uint16_t create_signal_count; > bool rx_is_free; > /* Used shared memory objects, struct ffa_shm_mem */ > struct list_head shm_list; > @@ -402,6 +404,15 @@ struct ffa_ctx { > 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[]; > }; >=20 > struct ffa_shm_mem { > @@ -436,6 +447,12 @@ static void *ffa_tx __read_mostly; > static DEFINE_SPINLOCK(ffa_rx_buffer_lock); > static DEFINE_SPINLOCK(ffa_tx_buffer_lock); >=20 > + > +/* Used to track domains that could not be torn down immediately. */ > +static struct timer ffa_teardown_timer; > +static struct list_head ffa_teardown_head; > +static DEFINE_SPINLOCK(ffa_teardown_lock); > + > static bool ffa_get_version(uint32_t *vers) > { > const struct arm_smccc_1_2_regs arg =3D { > @@ -853,7 +870,6 @@ static int32_t handle_partition_info_get(uint32_t w1,= uint32_t w2, uint32_t w3, > goto out_rx_release; > } >=20 > - > memcpy(ctx->rx, ffa_rx, sz); > } > ctx->rx_is_free =3D false; > @@ -992,53 +1008,75 @@ static void put_shm_pages(struct ffa_shm_mem *shm) > } > } >=20 > -static bool inc_ctx_shm_count(struct ffa_ctx *ctx) > +static bool inc_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx) > { > bool ret =3D true; >=20 > spin_lock(&ctx->lock); > + > + /* > + * 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); > + > if (ctx->shm_count >=3D FFA_MAX_SHM_COUNT) > ret =3D false; > else > ctx->shm_count++; > + > spin_unlock(&ctx->lock); >=20 > return ret; > } >=20 > -static void dec_ctx_shm_count(struct ffa_ctx *ctx) > +static void dec_ctx_shm_count(struct domain *d, struct ffa_ctx *ctx) > { > 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. > + */ > + if ( !ctx->shm_count ) > + put_domain(d); > + > spin_unlock(&ctx->lock); > } >=20 > -static struct ffa_shm_mem *alloc_ffa_shm_mem(struct ffa_ctx *ctx, > +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; >=20 > if ( page_count >=3D FFA_MAX_SHM_PAGE_COUNT ) > return NULL; > - if ( !inc_ctx_shm_count(ctx) ) > + if ( !inc_ctx_shm_count(d, ctx) ) > return NULL; >=20 > 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(ctx); > + dec_ctx_shm_count(d, ctx); >=20 > return shm; > } >=20 > -static void free_ffa_shm_mem(struct ffa_ctx *ctx, struct ffa_shm_mem *sh= m) > +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; >=20 > - dec_ctx_shm_count(ctx); > + dec_ctx_shm_count(d, ctx); > put_shm_pages(shm); > xfree(shm); > } > @@ -1306,7 +1344,7 @@ static void handle_mem_share(struct cpu_user_regs *= regs) > goto out_unlock; > } >=20 > - shm =3D alloc_ffa_shm_mem(ctx, page_count); > + shm =3D alloc_ffa_shm_mem(d, page_count); > if ( !shm ) > { > ret =3D FFA_RET_NO_MEMORY; > @@ -1350,7 +1388,7 @@ static void handle_mem_share(struct cpu_user_regs *= regs) >=20 > out: > if ( ret ) > - free_ffa_shm_mem(ctx, shm); > + free_ffa_shm_mem(d, shm); > out_unlock: > spin_unlock(&ctx->tx_lock); >=20 > @@ -1401,7 +1439,7 @@ static int handle_mem_reclaim(uint64_t handle, uint= 32_t flags) > } > else > { > - free_ffa_shm_mem(ctx, shm); > + free_ffa_shm_mem(d, shm); > } >=20 > return ret; > @@ -1486,6 +1524,41 @@ static bool ffa_handle_call(struct cpu_user_regs *= regs) > } > } >=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; > @@ -1501,11 +1574,14 @@ static int ffa_domain_init(struct domain *d) > if ( d->domain_id >=3D UINT16_MAX) > return -ERANGE; >=20 > - ctx =3D xzalloc(struct ffa_ctx); > + ctx =3D xzalloc_flex_struct(struct ffa_ctx, vm_destroy_bitmap, > + BITS_TO_LONGS(subscr_vm_destroyed_count)); > if ( !ctx ) > return -ENOMEM; >=20 > d->arch.tee =3D ctx; > + ctx->teardown_d =3D d; > + INIT_LIST_HEAD(&ctx->shm_list); >=20 > for ( n =3D 0; n < subscr_vm_created_count; n++ ) > { > @@ -1515,65 +1591,141 @@ static int ffa_domain_init(struct domain *d) > { > 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); > - ctx->create_signal_count =3D n; > - return -EIO; > + break; > } > } > - ctx->create_signal_count =3D subscr_vm_created_count; > - > - INIT_LIST_HEAD(&ctx->shm_list); > + vm_destroy_bitmap_init(ctx, n); > + if ( n !=3D subscr_vm_created_count ) > + return -EIO; >=20 > return 0; > } >=20 > -static bool is_in_subscr_list(const uint16_t *subscr, uint16_t start, > - uint16_t end, uint16_t sp_id) > +static void send_vm_destroyed(struct domain *d) > { > + struct ffa_ctx *ctx =3D d->arch.tee; > unsigned int n; > + int32_t res; >=20 > - for ( n =3D start; n < end; n++ ) > + for ( n =3D 0; n < subscr_vm_destroyed_count; n++ ) > { > - if ( subscr[n] =3D=3D sp_id ) > - return true; > - } > + if ( !test_bit(n, ctx->vm_destroy_bitmap) ) > + continue; >=20 > - return false; > + res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], get_vm_id= (d), > + FFA_MSG_SEND_VM_DESTROYED); > + I think here we should dinstinguish cases depending on the error received: - retry: we should keep the bit set and retry later - other: unset the bit as there is not much we can do but log it. The interrupted case can happen, we handle that already in the direct messa= ge request but we will get back here if that does not work after some retries = so putting it in the other category is ok i think. > + 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); > + } > + else > + { > + clear_bit(n, ctx->vm_destroy_bitmap); > + } > + } > } >=20 > -/* This function is supposed to undo what ffa_domain_init() has done */ > -static int ffa_domain_teardown(struct domain *d) > +static void reclaim_shms(struct domain *d) > { > struct ffa_ctx *ctx =3D d->arch.tee; > - unsigned int n; > + struct ffa_shm_mem *shm, *tmp; > int32_t res; >=20 > - if ( !ctx ) > - return 0; > + list_for_each_entry_safe(shm, tmp, &ctx->shm_list, list) > + { > + register_t handle_hi; > + register_t handle_lo; >=20 > - for ( n =3D 0; n < subscr_vm_destroyed_count; n++ ) > + uint64_to_regpair(&handle_hi, &handle_lo, shm->handle); > + res =3D ffa_mem_reclaim(handle_lo, handle_hi, 0); Same here as for the VM_DESTROYED, there are some error code that we should not reiterate on as they will also fail next time: - invalid parameters: stop and log an error, this will always fail - no memory: for now I would say do the same as invalid parameter with a co= mment maybe because we could retry and memory coud be available next time - abort: stop and log an error, this is a major fault on the other side - denied: retry. > + if ( res ) > + { > + printk(XENLOG_G_INFO "%pd: ffa: Failed to reclaim handle %#l= x : %d\n", > + d, shm->handle, res); > + } > + else > + { > + printk(XENLOG_G_DEBUG "%pd: ffa: Reclaimed handle %#lx\n", > + d, shm->handle); > + list_del(&shm->list); > + free_ffa_shm_mem(d, shm); > + } > + } > +} > + > +static void ffa_domain_teardown_continue(struct ffa_ctx *ctx, bool first= _time) > +{ > + struct ffa_ctx *next_ctx =3D NULL; > + > + send_vm_destroyed(ctx->teardown_d); > + reclaim_shms(ctx->teardown_d); > + > + if ( ctx->shm_count ) > + { If i do understand right you only retry if there are remaining SHM to recla= im but what if you have destroy messages that were not sent successfully, shouldn't we = reiterate in that case to send the destroy message again ? > + printk(XENLOG_G_INFO "%pd: ffa: Remaining unclaimed handles, ret= rying\n", ctx->teardown_d); > + > + ctx->teardown_expire =3D NOW() + FFA_CTX_TEARDOWN_DELAY; > + > + spin_lock(&ffa_teardown_lock); > + list_add_tail(&ctx->teardown_list, &ffa_teardown_head); > + /* Need to set a new timer for the next ctx in line */ > + next_ctx =3D list_first_entry(&ffa_teardown_head, struct ffa_ctx= , > + teardown_list); > + spin_unlock(&ffa_teardown_lock); > + } > + else > { > /* > - * Skip SPs subscribed to the VM created event that never was > - * notified of the VM creation due to an error during > - * ffa_domain_init(). > + * domain_destroy() might have been called (via put_domain() in > + * reclaim_shms()), so we can't touch the domain structure anymo= re. > */ > - if ( is_in_subscr_list(subscr_vm_created, ctx->create_signal_cou= nt, > - subscr_vm_created_count, > - subscr_vm_destroyed[n]) ) > - continue; > + xfree(ctx); >=20 > - res =3D ffa_direct_req_send_vm(subscr_vm_destroyed[n], get_vm_id= (d), > - FFA_MSG_SEND_VM_DESTROYED); > - > - if ( res ) > - printk(XENLOG_ERR "ffa: Failed to report destruction of vm_i= d %u to %u: res %d\n", > - get_vm_id(d), subscr_vm_destroyed[n], res); > + /* Only check if there has been a change to the teardown queue *= / > + if ( !first_time ) > + { > + spin_lock(&ffa_teardown_lock); > + next_ctx =3D list_first_entry_or_null(&ffa_teardown_head, > + struct ffa_ctx, teardown= _list); > + spin_unlock(&ffa_teardown_lock); > + } > } >=20 > + if ( next_ctx ) > + set_timer(&ffa_teardown_timer, next_ctx->teardown_expire); > +} > + > +static void ffa_teardown_timer_callback(void *arg) > +{ > + struct ffa_ctx *ctx; > + > + spin_lock(&ffa_teardown_lock); > + ctx =3D list_first_entry_or_null(&ffa_teardown_head, struct ffa_ctx, > + teardown_list); > + if ( ctx ) > + list_del(&ctx->teardown_list); > + spin_unlock(&ffa_teardown_lock); > + > + if ( ctx ) > + ffa_domain_teardown_continue(ctx, false /* !first_time */); > + else > + printk(XENLOG_G_ERR "%s: teardown list is empty\n", __func__); > +} > + > +/* This function is supposed to undo what ffa_domain_init() has done */ > +static int ffa_domain_teardown(struct domain *d) > +{ > + struct ffa_ctx *ctx =3D d->arch.tee; > + > + if ( !ctx ) > + return 0; > + > if ( ctx->rx ) > rxtx_unmap(ctx); >=20 > - XFREE(d->arch.tee); > + ffa_domain_teardown_continue(ctx, true /* first_time */); >=20 > return 0; > } > @@ -1739,6 +1891,9 @@ static bool ffa_probe(void) > if ( !init_sps() ) > goto err_free_ffa_tx; >=20 > + INIT_LIST_HEAD(&ffa_teardown_head); > + init_timer(&ffa_teardown_timer, ffa_teardown_timer_callback, NULL, 0= ); > + > return true; >=20 > err_free_ffa_tx: > --=20 > 2.34.1 >=20 Regards Bertrand From xen-devel-bounces@lists.xenproject.org Thu Feb 01 14:15:08 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 14:15:08 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674460.1049377 (Exim 4.92) (envelope-from ) id 1rVXqC-0001Kk-VS; Thu, 01 Feb 2024 14:14:56 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674460.1049377; Thu, 01 Feb 2024 14:14: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 1rVXqC-0001Kd-Rv; Thu, 01 Feb 2024 14:14:56 +0000 Received: by outflank-mailman (input) for mailman id 674460; Thu, 01 Feb 2024 14:14: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 1rVXqA-0001KX-Ta for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:14:54 +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 4443fa92-c10c-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 15:14:52 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a358ec50b7cso177054666b.0 for ; Thu, 01 Feb 2024 06:14: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 n11-20020a1709061d0b00b00a31805b4165sm7307095ejh.11.2024.02.01.06.14.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 06:14: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: 4443fa92-c10c-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706796892; x=1707401692; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=372ElkJtaiL6Ckt2N2GRS8UgDvCeS0ipS47J5ex3oPo=; b=U5Zzk9cy3F6p1AYSXBhqL5oXqA2X9BDsNV9ogxQes40DqjhOE5PrDq2aDuJ2iF2OMP gJff50FwrbgJaJKVboXV5g354hTuGSJPY9+t0juLJc0zqWsGzW+SFAkiCDdkcx9dAPcE XirwuZcr+O8DV2hdGcauORW/cg3kL1BkTD1TBYi9efLy35160NVDQKcIYm9gKRhSxdmv XVBEWA4cTWRnnznzTv3OpNEl4vkoX/a5n/wcZRkD49VUN1txHkp0kBB0ozAldVYXkPYt xAgvtNSIfn/hQoYox7N13DlOOpuZkl5yhMQV6sFWB1fPsNPuUIhqbPnxQzK9XvR9lrib ua8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706796892; x=1707401692; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=372ElkJtaiL6Ckt2N2GRS8UgDvCeS0ipS47J5ex3oPo=; b=PF95EWIS2qB8TYydqiWMyoCdqsPGShrTQZInlBP6NcsiVn59SVFL2si9G4GTAfGB1l vDtPkZeQr9T19mutbE+kc7lAXDbRjLlnKfMdpu46/5VnOZde77Eey1a6LjjC7F+XOfWf xh/BZEolyxeetvZHZc5IRifQntZZUmj5pw8eNZWOtHYD3WHwxVfnA/+wbA+DkzeUDs4B vWlLtDIYe70oo6ZR5pBVD0MgxEZXgApqBQdz+RCQpPefF0/ozxMJGklfNfRStcDqjwtz 1CJ/hUe2g4Ce2khnJy84ONpZ+t14syCAyMefsYS3iG1ibuhwO3GPsu2228HfRxqraLUK tKjw== X-Gm-Message-State: AOJu0YxllbpLXY5BLWCGcEm7vZclV0vLiE26fh4aSMKvhgOaGcJcx1RQ 9TqFFU0RZTziDpsPrmE5FVUvng7b/5EbFdbowmpiO0zXuZySMITBw9gPPCNgyQ== X-Google-Smtp-Source: AGHT+IGMs6lhETPsxHHCYuu4paYmqeShsaRHhh6gxYOmsr1GP9cGuFZ6nDDesUE42Ccxf37+yHDpjw== X-Received: by 2002:a17:906:f884:b0:a29:b31d:1dc6 with SMTP id lg4-20020a170906f88400b00a29b31d1dc6mr4608416ejb.6.1706796892038; Thu, 01 Feb 2024 06:14:52 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWrLCoi+13j4zvLjpgdICpGbP9M3IKMweasrcL5I5I6UVnXqoaByYfddo0BHjwYQc4u24nwrcIGpvOj/Sh6sMjpPELEuJOSoBkJ5RCqi50LGoxbAIu6SNLmfUBbzpUqh52JIRdWQ5FYC4LzCg== Message-ID: <47b5a1be-280c-4e8e-a5c5-6df7da657539@suse.com> Date: Thu, 1 Feb 2024 15:14:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] x86/p2m: aid the compiler in folding p2m_is_...() 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: <5d6c927e-7d7c-5754-e7eb-65d1e70f6222@suse.com> <7cce89f4-962e-bfbe-7d30-18fea7515bed@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 01.02.2024 14:32, George Dunlap wrote: > On Thu, Jun 23, 2022 at 12:54 PM Jan Beulich wrote: > >> By using | instead of || or (in the negated form) && chances increase >> for the compiler to recognize that both predicates can actually be >> folded into an expression requiring just a single branch (via OR-ing >> together the respective P2M_*_TYPES constants). >> >> Signed-off-by: Jan Beulich >> > > Sorry for the delay. Git complains that this patch is malformed: > > error: `git apply --index`: error: corrupt patch at line 28 > > Similar complaint from patchew when it was posted: > > https://patchew.org/Xen/5d6c927e-7d7c-5754-e7eb-65d1e70f6222@suse.com/ Not sure what to say. The patch surely is well-formed. It applies fine using patch (when not taken from email). When taken from email, patch mentions that it strips CRs (I'm running my email client on Windows), but the saved email still applies fine. "git am" indeed is unhappy when taking the plain file as saved from email, albeit here with an error different from yours. If I edit the saved email to retain just the From: and Subject: tags, all is fine. I can't tell what git doesn't like. The error messages (the one you see and the one I got) tell me nothing. I'm also not aware of there being a requirement that patches I send via email need to be "git am"-able (unlike in xsa.git, where I edit patches enough to be suitable for that), nor am I aware how I would convince my email client and/or server to omit whatever git doesn't like or to add whatever git is missing. Bottom line - your response would be actionable by me only in so far as I could switch to using "git send-email". Which I'm afraid I'm not going to do unless left with no other choice. The way I've been sending patches has worked well for over 20 years, and for different projects. (I'm aware Andrew has some special "Jan" command to apply patches I send, but I don't know any specifics.) Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 14:19:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 14:19:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674464.1049386 (Exim 4.92) (envelope-from ) id 1rVXuy-0003dh-KG; Thu, 01 Feb 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 674464.1049386; Thu, 01 Feb 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 1rVXuy-0003da-HU; Thu, 01 Feb 2024 14:19:52 +0000 Received: by outflank-mailman (input) for mailman id 674464; Thu, 01 Feb 2024 14:19: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 1rVXux-0003c4-Od for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:19:51 +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 f5e4368e-c10c-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 15:19:50 +0100 (CET) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-55a9008c185so1738283a12.1 for ; Thu, 01 Feb 2024 06:19: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 ev20-20020a056402541400b0055a8fe70387sm6856536edb.1.2024.02.01.06.19.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 06:19: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: f5e4368e-c10c-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706797190; x=1707401990; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xFLBrh7Dpw3f87TJClFlFdPkIP+m+X3DpeBb+FAMqqw=; b=PNI7jFTnDkJrprISyHNm5/JCws0Ort9DCoRhyRIgD4jcth7NqGqSqc0CpcxqtX4jYg L85KMwpFGpWywHXjAqxOiiTATHd4GJ1E7GwhDyUaJcHGdjYnKgPagKy91DuGUmGEoTks sVvrFa7SZPRC/9iQz9fyRaupjxTfbPs0rW6SqpH6TaJQE4QAjfsewHK7IDmQDvGDa2h7 a2Mi41mWn7+GNf4DCoHBYw3FIBsVb8E4MzhVH1MTK1b9DNwO8TF52QYNaEU+Rq8tP3UI eR9r2jN2tRque+hRXHOrJ3XqzZpa9DFDW0MVqA/aMed89nLHRp0IGW3NRrmzRkBjrRYI krQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706797190; x=1707401990; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xFLBrh7Dpw3f87TJClFlFdPkIP+m+X3DpeBb+FAMqqw=; b=r2HHmU0m9dce4+4KJcA7gQTs6wg3HH/bDh+ITU6AgV3zS+wevAlUX6YkE91Tdu7yh3 lFWdLbaD/MUYzAePbDi0JJrcXUzwBjGdbgM50IaKU0omLNHE5uNjtoQRt1o/8oeBCom2 U91F2wGztB/FLDaXWegdinjWu9V4sVAl5pPA9qZ0GZzKJd2x93SU5KQGckdCemguBXxf 5rwB9CZJApeH1E2TJ0GW/R5/NL7/7g25b6jqud/7d5/ymiAEm43GNzT5k4EiVcbZ+LJW c7oTiBLbQv0/Up/xS6pWR36q6RrvmhBA4hbTqHrhMqG+maUj/hCAQKjxW2wvxyDpiYIE G6HQ== X-Gm-Message-State: AOJu0Yz7mpWVjtOu/3FRqcqgCiLZhvBAxcV1zKw3sgq/h9uoSxckT2XV pW+RNb/XQCUuc7b3p5dAmH18WayQI5zMCsUQZarWXXMwSmA6FIVjGIYN/jRQNg== X-Google-Smtp-Source: AGHT+IEjsmIYEgx0oOGNg8gK4dNS2Sc9/aKI1hvXhaj3q0G54l/mXV66zL4dQRKZUW2UtAfPQtp3+Q== X-Received: by 2002:a50:8e43:0:b0:55f:5197:6314 with SMTP id 3-20020a508e43000000b0055f51976314mr4697303edx.18.1706797190022; Thu, 01 Feb 2024 06:19:50 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUBqgQZk9DK8Vom/o14kamV2ZuSDDHgUC0AQp3yBxYwUOGEmXiAYPGzLM3CQ20RXxd9iDYUmoddPqZUGol9geb9pxXvFY5GN4xMTU7yBbmI4kJoTzFb7L1oj1b7BAjpfNDnm+o2X2jtV4xc59RYoPUfyucokPaHc431aTtnsGeIJENOHMBiUSchSrHNsVDMGhPBbbB1uVf1IKIsuh9TGdVQdjz9bB1VYhLOSu95PHqDb4plwZFY5GdjeTJj+kGay3KWy8LrrBJyBooCFZQY+KG4WbsXXEVuWqgVak2BDDPmjt4X33fll2lgJEvRsV2QDWB+pezyb1vXk6rablH5Xe9foxJ/XAGwPFrIfbZrc8L71JakFnlV5S94jhb10dzSbpKuMQ== Message-ID: Date: Thu, 1 Feb 2024 15:19:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 07/15] xen/arm: add support for cache coloring configuration via device-tree Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-8-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > @@ -950,6 +951,11 @@ void __init create_domUs(void) > #endif > } > > + dt_property_read_string(node, "llc-colors", &llc_colors_str); > + if ( !llc_coloring_enabled && llc_colors_str) > + printk(XENLOG_WARNING > + "'llc-colors' found, but LLC coloring is disabled\n"); Why's this just a warning, when ... > @@ -960,6 +966,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); ... this results in panic()? > --- a/xen/common/llc-coloring.c > +++ b/xen/common/llc-coloring.c > @@ -254,6 +254,29 @@ int domain_set_llc_colors_domctl(struct domain *d, > return domain_check_colors(d); > } > > +int domain_set_llc_colors_from_str(struct domain *d, const char *str) __init ? > +{ > + int err; > + unsigned int *colors; > + > + if ( !str ) > + return domain_set_default_colors(d); > + > + colors = alloc_colors(max_nr_colors); > + if ( !colors ) > + return -ENOMEM; > + > + err = parse_color_config(str, colors, max_nr_colors, &d->num_llc_colors); > + if ( err ) > + { > + printk(XENLOG_ERR "Error parsing LLC color configuration."); Nit: No full stop at the end of log messages please. > + return err; > + } > + d->llc_colors = colors; > + > + return domain_check_colors(d); Same ordering issue as in the earlier patch, I think. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 14:21:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 14:21:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674467.1049397 (Exim 4.92) (envelope-from ) id 1rVXwS-0005T8-Vw; Thu, 01 Feb 2024 14:21:24 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674467.1049397; Thu, 01 Feb 2024 14: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 1rVXwS-0005T1-Sv; Thu, 01 Feb 2024 14:21:24 +0000 Received: by outflank-mailman (input) for mailman id 674467; Thu, 01 Feb 2024 14:21: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 1rVXwR-0005Sq-M2 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:21:23 +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 2cda519a-c10d-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 15:21:22 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-55efbaca48bso1327702a12.2 for ; Thu, 01 Feb 2024 06:21:22 -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 ev20-20020a056402541400b0055a8fe70387sm6856536edb.1.2024.02.01.06.21.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 06: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: 2cda519a-c10d-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706797282; x=1707402082; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9bIqj/x+kRtQHMH7oFV6HTCiWYHXei4IpsdLUZpA3ac=; b=O9Lm3MGY1790qmS18+KgOFjBY7j6xnKcmtyor6rVRuDcagJVZix9kPyiuiPkceob0k U3tiFSzJ65x8iVS8/dSrBIbNb2HH9DpJ1y61cPSpIrDe6RKOVGRVoxx9YT16BwQc3/SI PyVfBpBi19wzY47lelteiuFCSSb1i3hJSzH7IyPkE8sLMfh7cHQi/6R6oiWa/iF0fpwA 4yOuR3brwEcnABSj7nIwgDjUHg1urpf/eJ8e/3PDfaV5S9xYV+3ldIfrTFJtlJ2oaJxx AfXEJi2YBzLdefVeJenOieHuZpF9zHefFoRbSl6v39+NAwA2+wQyGOYvwo9o8me0voMV 4lJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706797282; x=1707402082; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9bIqj/x+kRtQHMH7oFV6HTCiWYHXei4IpsdLUZpA3ac=; b=HUnHYKdImpq4pe5lCjlqAvXkwOlMLV+bI+y7vCAOnR9hLNUbJtuaaiZKHb3p349hZj J1YXqsXukNdqehUzBYMeNU5XNtENvnJGOkvHwA3w+d+ewNJVQ4OZTMiZhnbTJhOaTm2k MwvuXyS/Qm3xObX1FAaBbezCRG8YSz3olmVnc9+3rZULbf9JqkIGWA7a/56U2JJp1aUT rgPDR8JRRtjIxW4fsbMfdUxhyyYMRbMjifP5HNUffl6w0p64vGu0N52i2sDuOIlxb/Fd XbiSFhiAh67por84vPFL00+nBiabHcuSEni9nZVUoj8+rWts5Vz1ZP24WTTERqaUUcFM T7ng== X-Gm-Message-State: AOJu0YyE2GjWmLBi6xddNbwn4C5SMnMJFd7JC62vTIzpZMarA1H43Y4N LttyUqKP0bvrbOGnhwUBJ5U7bWLbi5ywRVObnLhc+pJqDTB4eAE1n2wOBcG86g== X-Google-Smtp-Source: AGHT+IHCDcO+re9/6Et4j8ebOHRgtecY3ijparwiGLDuHCxKvvYmoiX3hLEoeuPhAczJQE0sHExA6Q== X-Received: by 2002:aa7:dad4:0:b0:55f:9337:7a22 with SMTP id x20-20020aa7dad4000000b0055f93377a22mr3417898eds.12.1706797282349; Thu, 01 Feb 2024 06:21:22 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWFab+X+uzE+y11Wu0iDF0hKJmFcX1Tb7+ot0Zuwaty3uexfiBTXOG7YXtL/+WA9U2WN0WYx29MS838tRnolMZ2MUizM5coZc6/QlMK2Ra4et5kigclXvGcKtNezq6lMGZCcn5ppjw+q7vZ5lMEdqqKbjQ8ansIm0crGbiRRRRJZl0C1C+dgJT19ysQuEVtKKNhRtlplQ4v5VTXexPg6PFfBNi012w9hVeWRnzOuYlBZTtB0zeW5Qk= Message-ID: Date: Thu, 1 Feb 2024 15:21:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 08/15] xen/page_alloc: introduce init_free_page_fields() helper Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-9-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > Introduce a new helper to initialize fields that have different uses for > free pages. > > Signed-off-by: Carlo Nonato Acked-by: Jan Beulich From xen-devel-bounces@lists.xenproject.org Thu Feb 01 14:24:39 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 14:24:39 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674472.1049407 (Exim 4.92) (envelope-from ) id 1rVXza-0006Qb-DT; Thu, 01 Feb 2024 14:24:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674472.1049407; Thu, 01 Feb 2024 14: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 1rVXza-0006QU-AU; Thu, 01 Feb 2024 14:24:38 +0000 Received: by outflank-mailman (input) for mailman id 674472; Thu, 01 Feb 2024 14:24: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 1rVXzY-0006Q7-P9 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:24: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 9f4902d4-c10d-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 15:24:34 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-55faa1e3822so1314746a12.1 for ; Thu, 01 Feb 2024 06:24: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 e8-20020a056402104800b0055ef2c893b3sm4540772edu.52.2024.02.01.06.24.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 06:24: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: 9f4902d4-c10d-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706797474; x=1707402274; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aTnwzMZUdVn2T6ESwgfPVQgOhtpjh2quV7YR2J9QNh4=; b=RLUJPpe5tMzV4VXZDuhVk10fKf155R+rsgpjq6njP0/STq+xzdyn6LopfS8QmilkOf S88nMzLpu+j9jkCihCLpngqIhzbWrXMItsf79olejnNPgfcsYDyWDovthH+bmTCRgmoZ l7v3NfsB8r9j9vaavVZuyCrhe5hHmdNZiUHvp0OeeUmwjZCBZT0PhjNBrGPBqeth9J8a OWbbaEvrMVHQs5JpbOUJrwY2AHNWB1zmVrDTt76DtFIo1bL1KTWlBVsXQylJ573LsuNK ONDt1K5Xl6FxwcIJOButWSYxrQgFUA24PPME8S88XJydu0nz94bIqa357InlhDOLlGQ5 kFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706797474; x=1707402274; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aTnwzMZUdVn2T6ESwgfPVQgOhtpjh2quV7YR2J9QNh4=; b=Pm4O7ug8mTJ0uCksGiN/0d/VrmVFzZ/5+DnAjFD2XBE6DI2ZFyd3lLBfDc5AYFxcy2 ceXI/F0SMeZw0FCq6gwS06/4gxwAzWSsteGzvBBhUTyo8OB6yas6Wy8Jo8wiBDFFdIbG Cl03L53eTtKnsr0ItSP/qFtvDnra0JON2y+9LJwdl1lVfkCjUwUqS2HqyknxnlkAj3Gn n3bIfl6j9/xxL0FpZy89PV3A9Z/lIVoNHWdjXC3zceSaLpcElkypqVw5C0TOMIIR839g k5HDn+bNdutVJZwkdmQimwG1afIQNhP94M3qM5WnBNGsNLMT9j0cHWgQy06m9DIcYQcP J6TA== X-Gm-Message-State: AOJu0YxqUdypb9IOSSgptELrFuSbH75C731w/wZR2jhs4n85r5ElvBfP JciwRMVGByIsmu5sSwFV1gy0VPxj1UxF2PCUW0oo28K6ukwYfZ/5yA87TmKMyA== X-Google-Smtp-Source: AGHT+IFaO3VX6mxNKUT73n4vv/ju0W/5o8JkQK0/kF58SmLXbknCcHVqpnJfHAgpO6g40I5uoL8Abg== X-Received: by 2002:a05:6402:3126:b0:55f:3fc1:a8b7 with SMTP id dd6-20020a056402312600b0055f3fc1a8b7mr3410268edb.7.1706797474292; Thu, 01 Feb 2024 06:24:34 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUqhF/GCPXrKrWIgvYcPZnp4ltseZjPvx8cPAWbjXgVphbTv5YNZNCF9mm0AlT8WBm4TpyB05Hpo1Bf037tCnwm1zTZlaRr77Ch0lxXGPqhs5ziffxId1XNW1evc33K5kN5hC5U0uu5w4bj5z7oceqJmjr5J2Cqn0iOnCoWGNNYW4MokbCS9afZgh+DWuX6uLpHb5vHsN3yYCFWooUCLsh5aSKeXlTRjYsJdsqQ+zY6VMAtN3ElV1c= Message-ID: <8a3f3c38-b290-417a-86cb-216e36182abe@suse.com> Date: Thu, 1 Feb 2024 15:24:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 09/15] xen/page_alloc: introduce preserved page flags macro Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-10-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > PGC_static and PGC_extra are flags that 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. While here you say where the "preserving" applies, ... > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -157,6 +157,8 @@ > #define PGC_static 0 > #endif > > +#define PGC_preserved (PGC_extra | PGC_static) ... nothing is said here. From the earlier version I also seem to recall that the constant was then used outside of assign_pages(). That would then mean amending whatever comment would be added here. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 14:49:25 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 14:49:25 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674477.1049416 (Exim 4.92) (envelope-from ) id 1rVYNQ-00055t-9O; Thu, 01 Feb 2024 14:49:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674477.1049416; Thu, 01 Feb 2024 14:49: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 1rVYNQ-00055m-6X; Thu, 01 Feb 2024 14:49:16 +0000 Received: by outflank-mailman (input) for mailman id 674477; Thu, 01 Feb 2024 14:49: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 1rVYNO-00052A-N6 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:49:14 +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 0fdbc749-c111-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 15:49:12 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-554fe147ddeso1329235a12.3 for ; Thu, 01 Feb 2024 06:49: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: 0fdbc749-c111-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minervasys-tech.20230601.gappssmtp.com; s=20230601; t=1706798951; x=1707403751; 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=dFrb14sFYxvQL3XHYJxoeThDXXBr7naHSSTej1GaxwM=; b=HkshQvKloTCdtnLdkPscnYQAHZr695KnweqO+dQX6FCvifY46YjvCkMeR4FBAGGIDk pzRRbAy8FJxua6TLs63JVXGE6HoywShHJKeSBXXshNUY3XVSAhNFs1PO0RYB7bt7kW3K eZXMy3YbtV27wFhYdkJoIMyUT095lxt9JPReoe2SLNgxGmPHw1a9m+pRXS6SgsKiCfmx Iz7YsyX06Ny90kHawBFxv0ZYClaq2hXBshEXMJi1J7fX4CCQawany2AUf23bd+j+/tfA BUzNMllNC9QkOdtIb1EFB/8F5zyOvDH0LxaKlMBWhG1Bfj8njRfuZLuvmlKtAQg/yncn NSqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706798951; x=1707403751; 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=dFrb14sFYxvQL3XHYJxoeThDXXBr7naHSSTej1GaxwM=; b=it69Y+mahH5/EjHLl2j1naCSXPhZhf51WmXt9VuMlLWTmKZXJdGxA/Bs30F0Pei9HJ J6EOQdHiwSjHFBWr/uJhb9Tb21TJxAx+ynH7UxHlKer07gM68MdpNGvoXmtnIIsew5KJ a9Un9q4BmB5r/JZNZYuquQykJbyssz9lg8ac48IPrH1q7I4ekLSOj5V7cuJK7l7aaB3u QIvnNxFvEupCH0nY76WmxhZo80oldjZ/NeYbsxfjglzOUcmWerXgJIWzomwRlu5O9O58 RZkhCKHuxB2B6CnxiWahlqtafW/zauoHqDREmbA4WkOJ3XhaAIAhTbGLWDwg0uERdlZV 53NQ== X-Gm-Message-State: AOJu0YwsVrP8KC/anWDYyFoRHnaMpkDM76xQ7DwGXhrBMzAns9nSdhUY XgRO0lMVPqhulY0czaJXIe7PPSGQvBDrOXBjxKjiMHOwYG8kfeuDH7/wV28YgVvaXtaEdLXBhm0 mCtU+a/q7673GxMzxvfrftN9jexBbB1/Z1B5S2Q== X-Google-Smtp-Source: AGHT+IGZeF8OndDYcaG2J0sgatGE/PKwuAz0nBmgVPylZnF2Kzym4hDGoLbgQtOieEEWLKmER+mEc/I1uizfcYgv5JA= X-Received: by 2002:a05:6402:b4d:b0:55e:ef54:1239 with SMTP id bx13-20020a0564020b4d00b0055eef541239mr3840572edb.10.1706798951541; Thu, 01 Feb 2024 06:49:11 -0800 (PST) MIME-Version: 1.0 References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-10-carlo.nonato@minervasys.tech> <8a3f3c38-b290-417a-86cb-216e36182abe@suse.com> In-Reply-To: <8a3f3c38-b290-417a-86cb-216e36182abe@suse.com> From: Carlo Nonato Date: Thu, 1 Feb 2024 15:49:00 +0100 Message-ID: Subject: Re: [PATCH v6 09/15] xen/page_alloc: introduce preserved page flags macro To: Jan Beulich Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jan, On Thu, Feb 1, 2024 at 3:24=E2=80=AFPM Jan Beulich wrot= e: > > On 29.01.2024 18:18, Carlo Nonato wrote: > > PGC_static and PGC_extra are flags that needs to be preserved when assi= gning > > a page. Define a new macro that groups those flags and use it instead o= f > > or'ing every time. > > While here you say where the "preserving" applies, ... > > > --- a/xen/common/page_alloc.c > > +++ b/xen/common/page_alloc.c > > @@ -157,6 +157,8 @@ > > #define PGC_static 0 > > #endif > > > > +#define PGC_preserved (PGC_extra | PGC_static) > > ... nothing is said here. From the earlier version I also seem to recall > that the constant was then used outside of assign_pages(). That would > then mean amending whatever comment would be added here. Yes, but it was used in places where the name didn't fit (to stop merging i= n free_heap_pages()) and so I thought it would've been better to use the constant only for one of the two concepts: only for preserved flags in assign_pages(). Are you suggesting adding a comment to this #define to clarify its usage? Thanks. > Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:00:04 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:00:04 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674481.1049426 (Exim 4.92) (envelope-from ) id 1rVYXn-0000GQ-6u; Thu, 01 Feb 2024 14:59:59 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674481.1049426; Thu, 01 Feb 2024 14: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 1rVYXn-0000GJ-4M; Thu, 01 Feb 2024 14:59:59 +0000 Received: by outflank-mailman (input) for mailman id 674481; Thu, 01 Feb 2024 14:59: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 1rVYXm-0000Ez-FD for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 14:59:58 +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 907b3e74-c112-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 15:59:57 +0100 (CET) Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-40eac352733so9228695e9.0 for ; Thu, 01 Feb 2024 06:59:57 -0800 (PST) Received: from fziglio-xenia-fedora.eng.citrite.net ([185.25.67.249]) by smtp.gmail.com with ESMTPSA id t12-20020a05600c450c00b0040d5ae2906esm4737894wmo.30.2024.02.01.06.59.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 06: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: 907b3e74-c112-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706799597; x=1707404397; 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=wUDi3+dPODjB9qZn1Kktd29eMC32bAroiLdFB6ZmDys=; b=K3/SWa1s4kczFXdltkie+9Xp2m8lRB8OPL9lEVfs1vpo+ZOZv2+wFEGSVq0Tdsyoqk unAOWIhHzgpH9DLEM1jpkTE3TCN3TEyvnNIwYqchGzPw3OZQrCYOp792H8soevgDgA+m 23bL7VS37+Otn7I03yuniVsQXmP35zg0yh21s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706799597; x=1707404397; 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=wUDi3+dPODjB9qZn1Kktd29eMC32bAroiLdFB6ZmDys=; b=GZUJA2t+HM3JSmHZYG0LabJYyH2OmfMXubI3+ybGGh1IqfEundjlq4pXEOuG2qQuh+ YQTD5sF26Sm3dWgEyPYZX6MVoqrTirzsyB274UxP4uDUI5j30BdpGPZNxrKO+j5ge85U uvXtJ7CKc9mCy0+ICXe69Dp/54yOVhmRB3UXxZrr6hN3AgN6OKemogHwHUTwEC53SoVQ Q7rUlBGNueXvRAi/CiU+Lw2fdaC0R/OXn8jW+hW30Hjg3k1hEj0wJvaNBGcn1/xk/Zmo Ar01vId1/dVnNmqIiLUCthOfhAItOTgiGQkJnuddcgJTVibPFYFyX/ifIQRsw3KetakJ Wv3g== X-Gm-Message-State: AOJu0YwUJoMfea7Y/Ha6xVeO81rtbpgLulsJQY2dDPGGg6UVud4olB57 pLaESkloJjXvvUQKSFuonOhK8Z2cbAZRGWtxZQVm9WzrBRibR9bZwuDPNOVX3D7wp9inIITrkma I X-Google-Smtp-Source: AGHT+IGKXDSVancIaYJuUcE2eBx3guV9apdjao5cLNe+I/ZxtXIKceERhfuR5AI+XVeftejihKvdCg== X-Received: by 2002:a05:600c:314f:b0:40e:4806:f436 with SMTP id h15-20020a05600c314f00b0040e4806f436mr3815617wmo.3.1706799596826; Thu, 01 Feb 2024 06:59:56 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUxxooJNPYJ9HJDdLtqIfzjdUuPvjPLr5HQUUTc2xl5zqJiCxdFIyWrnfY+BxsDrFMtGoSnUGK1LSuOL/tCV3h+VGrq+Tz8r+qulh9KkT9uQIMG+/JmRQvr3H9vcSSRU6emzqDG From: Frediano Ziglio To: George Dunlap , Andrew Cooper Cc: xen-devel@lists.xenproject.org, Frediano Ziglio Subject: [PATCH] Fix some typos in comments Date: Thu, 1 Feb 2024 14:59:43 +0000 Message-ID: <20240201145943.738531-1-frediano.ziglio@cloud.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Signed-off-by: Frediano Ziglio --- arch/x86/include/arch/processor.h | 2 +- include/xen/hvm/params.h | 2 +- include/xtf/console.h | 2 +- include/xtf/extable.h | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/arch/processor.h b/arch/x86/include/arch/processor.h index 0c33545..1c7e655 100644 --- a/arch/x86/include/arch/processor.h +++ b/arch/x86/include/arch/processor.h @@ -101,7 +101,7 @@ #define X86_EXC_TS 10 /* Invalid TSS. */ #define X86_EXC_NP 11 /* Segment Not Present. */ #define X86_EXC_SS 12 /* Stack-Segment Fault. */ -#define X86_EXC_GP 13 /* General Porection Fault. */ +#define X86_EXC_GP 13 /* General Protection Fault. */ #define X86_EXC_PF 14 /* Page Fault. */ #define X86_EXC_SPV 15 /* PIC Spurious Interrupt Vector. */ #define X86_EXC_MF 16 /* Maths fault (x87 FPU). */ diff --git a/include/xen/hvm/params.h b/include/xen/hvm/params.h index 886b986..0b7c05b 100644 --- a/include/xen/hvm/params.h +++ b/include/xen/hvm/params.h @@ -1,5 +1,5 @@ /* - * Xen public hvm paramter index + * Xen public hvm parameter index */ #ifndef XEN_PUBLIC_HVM_PARAMS_H diff --git a/include/xtf/console.h b/include/xtf/console.h index caec790..16a6a23 100644 --- a/include/xtf/console.h +++ b/include/xtf/console.h @@ -11,7 +11,7 @@ typedef void (*cons_output_cb)(const char *buf, size_t len); /* - * Register a console callback. Several callbacks can be registered for usful + * Register a console callback. Several callbacks can be registered for useful * destinations of console text. */ void register_console_callback(cons_output_cb cb); diff --git a/include/xtf/extable.h b/include/xtf/extable.h index e93331e..0668b7d 100644 --- a/include/xtf/extable.h +++ b/include/xtf/extable.h @@ -4,8 +4,8 @@ * Exception table support. * * Allows code to tag an instruction which might fault, and where to jump to - * in order to recover. For more complicated recovery, a cusom handler - * handler can be registerd. + * in order to recover. For more complicated recovery, a custom handler + * can be registered. */ #ifndef XTF_EXTABLE_H #define XTF_EXTABLE_H -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:07:48 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:07:48 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674488.1049437 (Exim 4.92) (envelope-from ) id 1rVYfH-0001s1-1d; Thu, 01 Feb 2024 15:07:43 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674488.1049437; Thu, 01 Feb 2024 15:07: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 1rVYfG-0001ru-V3; Thu, 01 Feb 2024 15:07:42 +0000 Received: by outflank-mailman (input) for mailman id 674488; Thu, 01 Feb 2024 15:07: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 1rVYfF-0001qg-7l for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:07:42 +0000 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id a3c32236-c113-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 16:07: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: a3c32236-c113-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1706800057; x=1707059257; bh=6BO9FSjLv6fOZG/S8ewf50JyY4Qtsp7WXzHDVSF0kA0=; 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=e3fOUv5JPF8xfqxmHkZpu6xyWD79Nvhbxi1diXgQOa6zY5ES89gOBIVNbyKpXeE7H AhVcwb3arI06btTyj7Pk9N/TKr7Iavd2E/aR2bACjKYK9pB+TCzE1Yxm+I9FWscf3L CKUWVBaY6E4WWiyisdm1ITZphfK6uMif0RBxB2KoR5lT3OJiHefg7lL9kX6JnzHi8Y eJH4VB8OsXw8k5HXhrjx+j2eo2T1l3kMrtkOlKuv19oA57fodEFD4DQG8Atpe997Wu YpxctvGyb0iHc480Gtt1MolvRBobMo5M9p0dNf5b1nyxPCfwsTIrXZSbvcpASgnYkn gswpN+aBaRkoQ== Date: Thu, 01 Feb 2024 15:07:29 +0000 To: Jan Beulich From: oxjo@proton.me Cc: "roger.pau@citrix.com" , "xen-devel@lists.xenproject.org" Subject: Re: Issue iommu unrecognized on amd computer Message-ID: <-sBcc1pvw26g_MiNhiisTW9NrekKWz2P3_8cIduaPlwkkm_v_GdSvMhlQtNBQU-v77vAP1_9EXWfpcuUdbk64mDIj-FBpyedXPvmkmgXAkc=@proton.me> In-Reply-To: <5cda514b-4b6f-4259-9dbc-bb1462eec13e@suse.com> References: <5cda514b-4b6f-4259-9dbc-bb1462eec13e@suse.com> Feedback-ID: 99814252:user:proton MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_GBYj6Y1YZQCBAVgd6bUn1cquVDPuaNM7JB5U3PQFQw" This is a multi-part message in MIME format. --b1_GBYj6Y1YZQCBAVgd6bUn1cquVDPuaNM7JB5U3PQFQw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I put it on the linux command line indeed, here is the log with iommu=3Ddeb= ug. I can install Xen with a debug build or test a fix if needed. I just need some guides because all I did for know is apt or dnf install Xe= n. Le jeudi 1 f=C3=A9vrier 2024 =C3=A0 11:57, Jan Beulich = a =C3=A9crit=C2=A0: > On 01.02.2024 09:16, oxjo@proton.me wrote: >=20 > > Following our interaction on matrix, I send you the boot log `xl dmesg`= output of my computer, booting with `iommu=3Ddebug` options on linux 6.6.1= 3-200.fc39. >=20 >=20 > There's no "iommu=3Ddebug" anywhere in sight: >=20 > (XEN) Command line: placeholder no-real-mode edd=3Doff >=20 > Did you mistakenly put it on the Linux command line? >=20 > Nevertheless there are relevant messages already without the extra > verbosity (and without you using a debug build of Xen, which would > be preferable): >=20 > (XEN) AMD-Vi: Warning: IVMD: [c9f1c000,c9f42000) is not (entirely) in res= erved memory > (XEN) AMD-Vi: Error: IVMD: page at c9f1c000 can't be converted > (XEN) AMD-Vi: Error initialization >=20 > Quoting the respective entry from the memory map: >=20 > (XEN) [00000000c8f58000, 00000000c9f57fff] (ACPI NVS) >=20 > Both Roger and I look to agree that this condition we have >=20 > if ( !(type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | > RAM_TYPE_UNUSABLE)) ) >=20 > is inverted in some way. We merely need to agree in which way it > wants adjusting. >=20 > Jan --b1_GBYj6Y1YZQCBAVgd6bUn1cquVDPuaNM7JB5U3PQFQw Content-Type: text/plain; name="boot (1).log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot (1).log" IFhlbiA0LjE4LjAKKFhFTikgWGVuIHZlcnNpb24gNC4xOC4wIChtb2NrYnVpbGRAKSAoZ2NjIChH Q0MpIDEzLjIuMSAyMDIzMTIwNSAoUmVkIEhhdCAxMy4yLjEtNikpIGRlYnVnPW4gV2VkIERlYyAx MyAxNzo1MDo0MiBVVEMgMjAyMwooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiAKKFhFTikgYnVpbGQt aWQ6IGVhNWQxOTYwYThkMDZmMzFiMDAwMzU1ZjQ2NjIxNjlmZTEyZDA5YTYKKFhFTikgQm9vdGxv YWRlcjogR1JVQiAyLjA2CihYRU4pIENvbW1hbmQgbGluZTogcGxhY2Vob2xkZXIgbm8tcmVhbC1t b2RlIGVkZD1vZmYgaW9tbXU9ZGVidWcKKFhFTikgWGVuIGltYWdlIGxvYWQgYmFzZSBhZGRyZXNz OiAweGMxYTAwMDAwCihYRU4pIFZpZGVvIGluZm9ybWF0aW9uOgooWEVOKSAgVkdBIGlzIGdyYXBo aWNzIG1vZGUgMTkyMHgxMDgwLCAzMiBicHAKKFhFTikgIFZCRS9EREMgbWV0aG9kczogbm9uZTsg RURJRCB0cmFuc2ZlciB0aW1lOiAwIHNlY29uZHMKKFhFTikgRGlzYyBpbmZvcm1hdGlvbjoKKFhF TikgIEZvdW5kIDAgTUJSIHNpZ25hdHVyZXMKKFhFTikgIEZvdW5kIDEgRUREIGluZm9ybWF0aW9u IHN0cnVjdHVyZXMKKFhFTikgQ1BVIFZlbmRvcjogQU1ELCBGYW1pbHkgMjUgKDB4MTkpLCBNb2Rl bCA4MCAoMHg1MCksIFN0ZXBwaW5nIDAgKHJhdyAwMGE1MGYwMCkKKFhFTikgRW5hYmxpbmcgU3Vw ZXJ2aXNvciBTaGFkb3cgU3RhY2tzCihYRU4pICAgLSBEaXNhYmxpbmcgUFYzMiBkdWUgdG8gQ0VU CihYRU4pIEVGSSBSQU0gbWFwOgooWEVOKSAgWzAwMDAwMDAwMDAwMDAwMDAsIDAwMDAwMDAwMDAw OWVmZmZdICh1c2FibGUpCihYRU4pICBbMDAwMDAwMDAwMDA5ZjAwMCwgMDAwMDAwMDAwMDA5ZmZm Zl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwMDAxMDAwMDAsIDAwMDAwMDAwMDliZmZmZmZd ICh1c2FibGUpCihYRU4pICBbMDAwMDAwMDAwOWMwMDAwMCwgMDAwMDAwMDAwOWRiMGZmZl0gKHJl c2VydmVkKQooWEVOKSAgWzAwMDAwMDAwMDlkYjEwMDAsIDAwMDAwMDAwMDllZmZmZmZdICh1c2Fi bGUpCihYRU4pICBbMDAwMDAwMDAwOWYwMDAwMCwgMDAwMDAwMDAwOWYwZWZmZl0gKEFDUEkgTlZT KQooWEVOKSAgWzAwMDAwMDAwMDlmMGYwMDAsIDAwMDAwMDAwYzJkNTdmZmZdICh1c2FibGUpCihY RU4pICBbMDAwMDAwMDBjMmQ1ODAwMCwgMDAwMDAwMDBjOGY1N2ZmZl0gKHJlc2VydmVkKQooWEVO KSAgWzAwMDAwMDAwYzhmNTgwMDAsIDAwMDAwMDAwYzlmNTdmZmZdIChBQ1BJIE5WUykKKFhFTikg IFswMDAwMDAwMGM5ZjU4MDAwLCAwMDAwMDAwMGM5ZmQ3ZmZmXSAoQUNQSSBkYXRhKQooWEVOKSAg WzAwMDAwMDAwYzlmZDgwMDAsIDAwMDAwMDAwYzlmZDlmZmZdICh1c2FibGUpCihYRU4pICBbMDAw MDAwMDBjOWZkYTAwMCwgMDAwMDAwMDBjOWZmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAw MDAwY2EwMDAwMDAsIDAwMDAwMDAwY2JmZmZmZmZdICh1c2FibGUpCihYRU4pICBbMDAwMDAwMDBj YzAwMDAwMCwgMDAwMDAwMDBjZGZmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwY2Yw MDAwMDAsIDAwMDAwMDAwY2ZmZmZmZmZdIChyZXNlcnZlZCkKKFhFTikgIFswMDAwMDAwMGY4MDAw MDAwLCAwMDAwMDAwMGZiZmZmZmZmXSAocmVzZXJ2ZWQpCihYRU4pICBbMDAwMDAwMDBmZGMwMDAw MCwgMDAwMDAwMDBmZGNmZmZmZl0gKHJlc2VydmVkKQooWEVOKSAgWzAwMDAwMDAwZmVkODAwMDAs IDAwMDAwMDAwZmVkODBmZmZdIChyZXNlcnZlZCkKKFhFTikgIFswMDAwMDAwMTAwMDAwMDAwLCAw MDAwMDAwZmVlMmZmZmZmXSAodXNhYmxlKQooWEVOKSAgWzAwMDAwMDBmZWUzMDAwMDAsIDAwMDAw MDEwMmZmZmZmZmZdIChyZXNlcnZlZCkKKFhFTikgQUNQSTogUlNEUCBDOUZENzAxNCwgMDAyNCAo cjIgTEVOT1ZPKQooWEVOKSBBQ1BJOiBYU0RUIEM5RkQ1MTg4LCAwMTA0IChyMSBMRU5PVk8gVFAt UjI1ICAgICAgIDExMzAgUFRFQyAgICAgICAgMikKKFhFTikgQUNQSTogRkFDUCBDMzk2NDAwMCwg MDExNCAocjYgTEVOT1ZPIFRQLVIyNSAgICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFD UEk6IERTRFQgQzM5NEMwMDAsIDEyNzkxIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgSU5U TCAyMDE4MDMxMykKKFhFTikgQUNQSTogRkFDUyBDOURGODAwMCwgMDA0MAooWEVOKSBBQ1BJOiBT U0RUIEM1RTc0MDAwLCAwMEEyIChyMSBMRU5PVk8gUElEMFNzZHQgICAgICAgIDEgSU5UTCAyMDE4 MDMxMykKKFhFTikgQUNQSTogU1NEVCBDNUU3MzAwMCwgMDc1MiAocjEgTEVOT1ZPIFVzYkNUYWJs ICAgICAgICAxIElOVEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzVFNjYwMDAsIDczNDUg KHIyIExFTk9WTyBUUC1SMjUgICAgICAgICAgMiBNU0ZUICAyMDAwMDAyKQooWEVOKSBBQ1BJOiBN U0RNIEM1QjdCMDAwLCAwMDU1IChyMyBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAg ICAgMikKKFhFTikgQUNQSTogQkFUQiBDNUI2NjAwMCwgMDA0QSAocjIgTEVOT1ZPIFRQLVIyNSAg ICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IEhQRVQgQzM5NjMwMDAsIDAwMzgg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBB UElDIEMzOTYyMDAwLCAwMTM4IChyMiBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAg ICAgMikKKFhFTikgQUNQSTogTUNGRyBDMzk2MTAwMCwgMDAzQyAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNCU1QgQzM5NjAwMDAsIDAwMzAg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBX U01UIEMzOTVGMDAwLCAwMDI4IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAg ICAgMikKKFhFTikgQUNQSTogVkZDVCBDMzkzRTAwMCwgRDg4NCAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNTRFQgQzM5MzgwMDAsIDUzNTQg KHIyIExFTk9WTyBUUC1SMjUgICAgICAgICAgMSBBTUQgICAgICAgICAxKQooWEVOKSBBQ1BJOiBD UkFUIEMzOTM3MDAwLCAwRUMwIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAg ICAgMikKKFhFTikgQUNQSTogQ0RJVCBDMzkzNjAwMCwgMDAyOSAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IEZQRFQgQzVCNjcwMDAsIDAwMzQg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBT U0RUIEMzOTM1MDAwLCAwMTQ5IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4 MDMxMykKKFhFTikgQUNQSTogU1NEVCBDMzkzMzAwMCwgMTRDMyAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAgICAxIElOVEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzM5MzEwMDAsIDE1QTgg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBBQ1BJOiBT U0RUIEMzOTJEMDAwLCAzQjBFIChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4 MDMxMykKKFhFTikgQUNQSTogQkdSVCBDMzkyQzAwMCwgMDAzOCAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAxMTMwIFBURUMgICAgICAgIDIpCihYRU4pIEFDUEk6IFNTRFQgQzM5MkIwMDAsIDAyNEQg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBBQ1BJOiBT U0RUIEMzOTI5MDAwLCAxNEM0IChyMSBMRU5PVk8gVFAtUjI1ICAgICAgICAgIDEgSU5UTCAyMDE4 MDMxMykKKFhFTikgQUNQSTogU1NEVCBDMzkyODAwMCwgMEFCNyAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAgICAxIElOVEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFVFRkkgQzlERjcwMDAsIDAwQzYg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgMTEzMCBQVEVDICAgICAgICAyKQooWEVOKSBBQ1BJOiBJ VlJTIEMzOTI3MDAwLCAwMUU0IChyMiBMRU5PVk8gVFAtUjI1ICAgICAgIDExMzAgUFRFQyAgICAg ICAgMikKKFhFTikgQUNQSTogU1NEVCBDNUU3MjAwMCwgMDA5MCAocjEgTEVOT1ZPIFRQLVIyNSAg ICAgICAgICAxIElOVEwgMjAxODAzMTMpCihYRU4pIEFDUEk6IFNTRFQgQzVFNzEwMDAsIDA5OEQg KHIxIExFTk9WTyBUUC1SMjUgICAgICAgICAgMSBJTlRMIDIwMTgwMzEzKQooWEVOKSBTeXN0ZW0g UkFNOiA2NDMwMk1CICg2NTg0NTQ3NmtCKQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91 bmQKKFhFTikgRmFraW5nIGEgbm9kZSBhdCAwMDAwMDAwMDAwMDAwMDAwLTAwMDAwMDBmZWUzMDAw MDAKKFhFTikgRG9tYWluIGhlYXAgaW5pdGlhbGlzZWQKKFhFTikgdmVzYWZiOiBmcmFtZWJ1ZmZl ciBhdCAweDAwMDAwMDAwZDAwMDAwMDAsIG1hcHBlZCB0byAweGZmZmY4MmMwMDAyMDEwMDAsIHVz aW5nIDgxMjhrLCB0b3RhbCA4MTI4awooWEVOKSB2ZXNhZmI6IG1vZGUgaXMgMTkyMHgxMDgweDMy LCBsaW5lbGVuZ3RoPTc2ODAsIGZvbnQgOHgxNgooWEVOKSB2ZXNhZmI6IFRydWVjb2xvcjogc2l6 ZT04Ojg6ODo4LCBzaGlmdD0yNDoxNjo4OjAKKFhFTikgU01CSU9TIDMuMyBwcmVzZW50LgooWEVO KSBBTUQtVmk6IElWUlMgQmxvY2s6IEZvdW5kIHR5cGUgMHgxMCBmbGFncyAweGIwIGxlbiAweDQ4 IGlkIDB4MgooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IEZvdW5kIHR5cGUgMHgxMSBmbGFncyAw eGIwIGxlbiAweDU4IGlkIDB4MgooWEVOKSBBTUQtVmk6IFVzaW5nIElWSEQgdHlwZSAweDExCihY RU4pIEFNRC1WaTogRm91bmQgTVNJIGNhcGFiaWxpdHkgYmxvY2sgYXQgMHg2NAooWEVOKSBVc2lu ZyBBUElDIGRyaXZlciBkZWZhdWx0CihYRU4pIEFDUEk6IFBNLVRpbWVyIElPIFBvcnQ6IDB4NDA4 ICgzMiBiaXRzKQooWEVOKSBBQ1BJOiB2NSBTTEVFUCBJTkZPOiBjb250cm9sWzE6MF0sIHN0YXR1 c1sxOjBdCihYRU4pIEFDUEk6IFNMRUVQIElORk86IHBtMXhfY250WzE6NDA0LDE6MF0sIHBtMXhf ZXZ0WzE6NDAwLDE6MF0KKFhFTikgQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBp biBGQURUIC0gYzlkZjgwMDAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzIKKFhFTikgQUNQSTog ICAgICAgICAgICAgd2FrZXVwX3ZlY1tjOWRmODAwY10sIHZlY19zaXplWzIwXQooWEVOKSBPdmVy cmlkaW5nIEFQSUMgZHJpdmVyIHdpdGggYmlnc21wCihYRU4pIEFDUEk6IElPQVBJQyAoaWRbMHgy MF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKKFhFTikgSU9BUElDWzBdOiBhcGlj X2lkIDMyLCB2ZXJzaW9uIDMzLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzCihYRU4pIEFD UEk6IElPQVBJQyAoaWRbMHgyMV0gYWRkcmVzc1sweGZlYzAxMDAwXSBnc2lfYmFzZVsyNF0pCihY RU4pIElPQVBJQ1sxXTogYXBpY19pZCAzMywgdmVyc2lvbiAzMywgYWRkcmVzcyAweGZlYzAxMDAw LCBHU0kgMjQtNTUKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgMCBnbG9i YWxfaXJxIDIgZGZsIGRmbCkKKFhFTikgQUNQSTogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEg OSBnbG9iYWxfaXJxIDkgbG93IGxldmVsKQooWEVOKSBBQ1BJOiBIUEVUIGlkOiAweDQzNTM4MjEw IGJhc2U6IDB4ZmVkMDAwMDAKKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRpb24gMDogYmFzZSBm ODAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSAzZgooWEVOKSBQQ0k6IE1DRkcgYXJlYSBh dCBmODAwMDAwMCByZXNlcnZlZCBpbiBFODIwCihYRU4pIFBDSTogVXNpbmcgTUNGRyBmb3Igc2Vn bWVudCAwMDAwIGJ1cyAwMC0zZgooWEVOKSBBQ1BJOiBCR1JUOiBpbnZhbGlkYXRpbmcgdjEgaW1h Z2UgYXQgMHhiZDY1NjAxOAooWEVOKSBVc2luZyBBQ1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3Vy YXRpb24gaW5mb3JtYXRpb24KKFhFTikgU01QOiBBbGxvd2luZyAxNiBDUFVzICgwIGhvdHBsdWcg Q1BVcykKKFhFTikgSVJRIGxpbWl0czogNTYgR1NJLCAzMjcyIE1TSS9NU0ktWAooWEVOKSBDUFUw OiAxNjAwIC4uLiAyMDAwIE1IegooWEVOKSB4c3RhdGU6IHNpemU6IDB4OTg4IGFuZCBzdGF0ZXM6 IDB4MjA3CihYRU4pIENQVTA6IEFNRCBGYW0xOWggbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5h YmxlZAooWEVOKSBWdWxuZXJhYmxlIHRvIFNSU08sIHdpdGhvdXQgc3VpdGFibGUgbWljcm9jb2Rl IHRvIG1pdGlnYXRlCihYRU4pIFNwZWN1bGF0aXZlIG1pdGlnYXRpb24gZmFjaWxpdGllczoKKFhF TikgICBIYXJkd2FyZSBoaW50czogU1RJQlBfQUxXQVlTIElCUlNfRkFTVCBJQlJTX1NBTUVfTU9E RQooWEVOKSAgIEhhcmR3YXJlIGZlYXR1cmVzOiBJQlBCIElCUlMgU1RJQlAgU1NCRCBQU0ZECihY RU4pICAgQ29tcGlsZWQtaW4gc3VwcG9ydDogSU5ESVJFQ1RfVEhVTksgU0hBRE9XX1BBR0lORwoo WEVOKSAgIFhlbiBzZXR0aW5nczogQlRJLVRodW5rIEpNUCwgU1BFQ19DVFJMOiBJQlJTKyBTVElC UCsgU1NCRC0gUFNGRC0sIE90aGVyOiBJQlBCLWN0eHQgQlJBTkNIX0hBUkRFTgooWEVOKSAgIFN1 cHBvcnQgZm9yIEhWTSBWTXM6IE1TUl9TUEVDX0NUUkwgTVNSX1ZJUlRfU1BFQ19DVFJMIFJTQgoo WEVOKSAgIFN1cHBvcnQgZm9yIFBWIFZNczogTm9uZQooWEVOKSAgIFhQVEkgKDY0LWJpdCBQViBv bmx5KTogRG9tMCBkaXNhYmxlZCwgRG9tVSBkaXNhYmxlZCAod2l0aG91dCBQQ0lEKQooWEVOKSAg IFBWIEwxVEYgc2hhZG93aW5nOiBEb20wIGRpc2FibGVkLCBEb21VIGRpc2FibGVkCihYRU4pIFVz aW5nIHNjaGVkdWxlcjogU01QIENyZWRpdCBTY2hlZHVsZXIgcmV2MiAoY3JlZGl0MikKKFhFTikg SW5pdGlhbGl6aW5nIENyZWRpdDIgc2NoZWR1bGVyCihYRU4pICBsb2FkX3ByZWNpc2lvbl9zaGlm dDogMTgKKFhFTikgIGxvYWRfd2luZG93X3NoaWZ0OiAzMAooWEVOKSAgdW5kZXJsb2FkX2JhbGFu Y2VfdG9sZXJhbmNlOiAwCihYRU4pICBvdmVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogLTMKKFhF TikgIHJ1bnF1ZXVlcyBhcnJhbmdlbWVudDogc29ja2V0CihYRU4pICBjYXAgZW5mb3JjZW1lbnQg Z3JhbnVsYXJpdHk6IDEwbXMKKFhFTikgbG9hZCB0cmFja2luZyB3aW5kb3cgbGVuZ3RoIDEwNzM3 NDE4MjQgbnMKKFhFTikgUGxhdGZvcm0gdGltZXIgaXMgMTQuMzE4TUh6IEhQRVQKKFhFTikgRGV0 ZWN0ZWQgMTk5Ni4yNTggTUh6IHByb2Nlc3Nvci4KKFhFTikgRnJlZWQgMTAyMGtCIHVudXNlZCBC U1MgbWVtb3J5CihYRU4pIGFsdCB0YWJsZSBmZmZmODJkMDQwNDViZDk4IC0+IGZmZmY4MmQwNDA0 NjkyYTgKKFhFTikgQU1ELVZpOiBJT01NVSBFeHRlbmRlZCBGZWF0dXJlczoKKFhFTikgLSBQZXJp cGhlcmFsIFBhZ2UgU2VydmljZSBSZXF1ZXN0CihYRU4pIC0geDJBUElDCihYRU4pIC0gTlggYml0 CihYRU4pIC0gSW52YWxpZGF0ZSBBbGwgQ29tbWFuZAooWEVOKSAtIEd1ZXN0IEFQSUMKKFhFTikg LSBQZXJmb3JtYW5jZSBDb3VudGVycwooWEVOKSAtIEhvc3QgQWRkcmVzcyBUcmFuc2xhdGlvbiBT aXplOiAweDIKKFhFTikgLSBHdWVzdCBBZGRyZXNzIFRyYW5zbGF0aW9uIFNpemU6IDAKKFhFTikg LSBHdWVzdCBDUjMgUm9vdCBUYWJsZSBMZXZlbDogMHgxCihYRU4pIC0gTWF4aW11bSBQQVNJRDog MHhmCihYRU4pIC0gU01JIEZpbHRlciBSZWdpc3RlcjogMHgxCihYRU4pIC0gU01JIEZpbHRlciBS ZWdpc3RlciBDb3VudDogMHgxCihYRU4pIC0gR3Vlc3QgVmlydHVhbCBBUElDIE1vZGVzOiAweDEK KFhFTikgLSBEdWFsIFBQUiBMb2c6IDB4MgooWEVOKSAtIER1YWwgRXZlbnQgTG9nOiAweDIKKFhF TikgLSBVc2VyIC8gU3VwZXJ2aXNvciBQYWdlIFByb3RlY3Rpb24KKFhFTikgLSBEZXZpY2UgVGFi bGUgU2VnbWVudGF0aW9uOiAweDMKKFhFTikgLSBQUFIgTG9nIE92ZXJmbG93IEVhcmx5IFdhcm5p bmcKKFhFTikgLSBQUFIgQXV0b21hdGljIFJlc3BvbnNlCihYRU4pIC0gTWVtb3J5IEFjY2VzcyBS b3V0aW5nIGFuZCBDb250cm9sOiAwCihYRU4pIC0gQmxvY2sgU3RvcE1hcmsgTWVzc2FnZQooWEVO KSAtIFBlcmZvcm1hbmNlIE9wdGltaXphdGlvbgooWEVOKSAtIE1TSSBDYXBhYmlsaXR5IE1NSU8g QWNjZXNzCihYRU4pIC0gR3Vlc3QgSS9PIFByb3RlY3Rpb24KKFhFTikgLSBFbmhhbmNlZCBQUFIg SGFuZGxpbmcKKFhFTikgLSBBdHRyaWJ1dGUgRm9yd2FyZAooWEVOKSAtIEludmFsaWRhdGUgSU9U TEIgVHlwZQooWEVOKSAtIFZNIFRhYmxlIFNpemU6IDAKKFhFTikgLSBHdWVzdCBBY2Nlc3MgQml0 IFVwZGF0ZSBEaXNhYmxlCihYRU4pIEFNRC1WaTogQUNQSSBUYWJsZToKKFhFTikgQU1ELVZpOiAg U2lnbmF0dXJlIElWUlMKKFhFTikgQU1ELVZpOiAgTGVuZ3RoIDB4MWU0CihYRU4pIEFNRC1WaTog IFJldmlzaW9uIDB4MgooWEVOKSBBTUQtVmk6ICBDaGVja1N1bSAweDFhCihYRU4pIEFNRC1WaTog IE9FTV9JZCBMRU5PVk8KKFhFTikgQU1ELVZpOiAgT0VNX1RhYmxlX0lkIFRQLVIyNSAgCihYRU4p IEFNRC1WaTogIE9FTV9SZXZpc2lvbiAweDExMzAKKFhFTikgQU1ELVZpOiAgQ3JlYXRvcl9JZCBQ VEVDCihYRU4pIEFNRC1WaTogIENyZWF0b3JfUmV2aXNpb24gMHgyCihYRU4pIEFNRC1WaTogSVZS UyBCbG9jazogdHlwZSAweDEwIGZsYWdzIDB4YjAgbGVuIDB4NDggaWQgMHgyCihYRU4pIEFNRC1W aTogSVZSUyBCbG9jazogdHlwZSAweDExIGZsYWdzIDB4YjAgbGVuIDB4NTggaWQgMHgyCihYRU4p IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHgzIGlkIDB4OCBmbGFncyAwCihYRU4p IEFNRC1WaTogIERldl9JZCBSYW5nZTogMHg4IC0+IDB4ZmZmZQooWEVOKSBBTUQtVmk6IElWSEQg RGV2aWNlIEVudHJ5OiB0eXBlIDB4NDMgaWQgMHhmZjAwIGZsYWdzIDAKKFhFTikgQU1ELVZpOiAg RGV2X0lkIFJhbmdlOiAweGZmMDAgLT4gMHhmZmZmIGFsaWFzIDB4YTUKKFhFTikgQU1ELVZpOiBJ VkhEIERldmljZSBFbnRyeTogdHlwZSAwIGlkIDAgZmxhZ3MgMAooWEVOKSBBTUQtVmk6IElWSEQg RGV2aWNlIEVudHJ5OiB0eXBlIDB4NDggaWQgMCBmbGFncyAwCihYRU4pIEFNRC1WaTogSVZIRCBT cGVjaWFsOiAwMDAwOjAwOjE0LjAgdmFyaWV0eSAweDIgaGFuZGxlIDAKKFhFTikgQU1ELVZpOiBJ VkhEIERldmljZSBFbnRyeTogdHlwZSAweDQ4IGlkIDAgZmxhZ3MgMHhkNwooWEVOKSBBTUQtVmk6 IElWSEQgU3BlY2lhbDogMDAwMDowMDoxNC4wIHZhcmlldHkgMHgxIGhhbmRsZSAweDIwCihYRU4p IEFNRC1WaTogSVZIRCBEZXZpY2UgRW50cnk6IHR5cGUgMHg0OCBpZCAwIGZsYWdzIDAKKFhFTikg QU1ELVZpOiBJVkhEIFNwZWNpYWw6IDAwMDA6MDA6MDAuMSB2YXJpZXR5IDB4MSBoYW5kbGUgMHgy MQooWEVOKSBBTUQtVmk6IElWUlMgQmxvY2s6IHR5cGUgMHgyMSBmbGFncyAweDggbGVuIDB4MjAg aWQgMHgxMDAKKFhFTikgQU1ELVZpOiBJVk1EIEJsb2NrOiB0eXBlIDB4MjEgcGh5cyAweGM5ZjFj MDAwIGxlbiAweDI2MDAwCihYRU4pIEFNRC1WaTogV2FybmluZzogSVZNRDogW2M5ZjFjMDAwLGM5 ZjQyMDAwKSBpcyBub3QgKGVudGlyZWx5KSBpbiByZXNlcnZlZCBtZW1vcnkKKFhFTikgQU1ELVZp OiBFcnJvcjogSVZNRDogcGFnZSBhdCBjOWYxYzAwMCBjYW4ndCBiZSBjb252ZXJ0ZWQKKFhFTikg QU1ELVZpOiBFcnJvciBpbml0aWFsaXphdGlvbgooWEVOKSBJL08gdmlydHVhbGlzYXRpb24gZGlz YWJsZWQKKFhFTikgRW5hYmxpbmcgQVBJQyBtb2RlOiAgUGh5c2ljYWwuICBVc2luZyAyIEkvTyBB UElDcwooWEVOKSBFTkFCTElORyBJTy1BUElDIElSUXMKKFhFTikgIC0+IFVzaW5nIG5ldyBBQ0sg bWV0aG9kCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0x IHBpbjI9LTEKKFhFTikgQWxsb2NhdGVkIGNvbnNvbGUgcmluZyBvZiA2NCBLaUIuCihYRU4pIEhW TTogQVNJRHMgZW5hYmxlZC4KKFhFTikgU1ZNOiBTdXBwb3J0ZWQgYWR2YW5jZWQgZmVhdHVyZXM6 CihYRU4pICAtIE5lc3RlZCBQYWdlIFRhYmxlcyAoTlBUKQooWEVOKSAgLSBMYXN0IEJyYW5jaCBS ZWNvcmQgKExCUikgVmlydHVhbGlzYXRpb24KKFhFTikgIC0gTmV4dC1SSVAgU2F2ZWQgb24gI1ZN RVhJVAooWEVOKSAgLSBWTUNCIENsZWFuIEJpdHMKKFhFTikgIC0gRGVjb2RlQXNzaXN0cwooWEVO KSAgLSBWaXJ0dWFsIFZNTE9BRC9WTVNBVkUKKFhFTikgIC0gVmlydHVhbCBHSUYKKFhFTikgIC0g UGF1c2UtSW50ZXJjZXB0IEZpbHRlcgooWEVOKSAgLSBQYXVzZS1JbnRlcmNlcHQgRmlsdGVyIFRo cmVzaG9sZAooWEVOKSAgLSBUU0MgUmF0ZSBNU1IKKFhFTikgIC0gTlBUIFN1cGVydmlzb3IgU2hh ZG93IFN0YWNrCihYRU4pICAtIE1TUl9TUEVDX0NUUkwgdmlydHVhbGlzYXRpb24KKFhFTikgSFZN OiBTVk0gZW5hYmxlZAooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lzdGVkIFBhZ2luZyAoSEFQKSBk ZXRlY3RlZAooWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCCihYRU4pIGFs dCB0YWJsZSBmZmZmODJkMDQwNDViZDk4IC0+IGZmZmY4MmQwNDA0NjkyYTgKKFhFTikgQnJvdWdo dCB1cCAxNiBDUFVzCihYRU4pIFNjaGVkdWxpbmcgZ3JhbnVsYXJpdHk6IGNwdSwgMSBDUFUgcGVy IHNjaGVkLXJlc291cmNlCihYRU4pIEluaXRpYWxpemluZyBDcmVkaXQyIHNjaGVkdWxlcgooWEVO KSAgbG9hZF9wcmVjaXNpb25fc2hpZnQ6IDE4CihYRU4pICBsb2FkX3dpbmRvd19zaGlmdDogMzAK KFhFTikgIHVuZGVybG9hZF9iYWxhbmNlX3RvbGVyYW5jZTogMAooWEVOKSAgb3ZlcmxvYWRfYmFs YW5jZV90b2xlcmFuY2U6IC0zCihYRU4pICBydW5xdWV1ZXMgYXJyYW5nZW1lbnQ6IHNvY2tldAoo WEVOKSAgY2FwIGVuZm9yY2VtZW50IGdyYW51bGFyaXR5OiAxMG1zCihYRU4pIGxvYWQgdHJhY2tp bmcgd2luZG93IGxlbmd0aCAxMDczNzQxODI0IG5zCihYRU4pIEFkZGluZyBjcHUgMCB0byBydW5x dWV1ZSAwCihYRU4pICBGaXJzdCBjcHUgb24gcnVucXVldWUsIGFjdGl2YXRpbmcKKFhFTikgQWRk aW5nIGNwdSAxIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSAyIHRvIHJ1bnF1ZXVlIDAK KFhFTikgQWRkaW5nIGNwdSAzIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA0IHRvIHJ1 bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA1IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNw dSA2IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA3IHRvIHJ1bnF1ZXVlIDAKKFhFTikg QWRkaW5nIGNwdSA4IHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRkaW5nIGNwdSA5IHRvIHJ1bnF1ZXVl IDAKKFhFTikgQWRkaW5nIGNwdSAxMCB0byBydW5xdWV1ZSAwCihYRU4pIEFkZGluZyBjcHUgMTEg dG8gcnVucXVldWUgMAooWEVOKSBBZGRpbmcgY3B1IDEyIHRvIHJ1bnF1ZXVlIDAKKFhFTikgQWRk aW5nIGNwdSAxMyB0byBydW5xdWV1ZSAwCihYRU4pIEFkZGluZyBjcHUgMTQgdG8gcnVucXVldWUg MAooWEVOKSBBZGRpbmcgY3B1IDE1IHRvIHJ1bnF1ZXVlIDAKKFhFTikgbWNoZWNrX3BvbGw6IE1h Y2hpbmUgY2hlY2sgcG9sbGluZyB0aW1lciBzdGFydGVkLgooWEVOKSBOWCAoRXhlY3V0ZSBEaXNh YmxlKSBwcm90ZWN0aW9uIGFjdGl2ZQooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDEwOTYgUElSUXMK KFhFTikgKioqIEJ1aWxkaW5nIGEgUFYgRG9tMCAqKioKKFhFTikgIFhlbiAga2VybmVsOiA2NC1i aXQsIGxzYiwgY29tcGF0MzIKKFhFTikgIERvbTAga2VybmVsOiA2NC1iaXQsIGxzYiwgcGFkZHIg MHgxMDAwMDAwIC0+IDB4NGEwMDAwMAooWEVOKSBQSFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6 CihYRU4pICBEb20wIGFsbG9jLjogICAwMDAwMDAwYzMwMDAwMDAwLT4wMDAwMDAwYzM4MDAwMDAw ICgxNjIxOTU2NCBwYWdlcyB0byBiZSBhbGxvY2F0ZWQpCihYRU4pICBJbml0LiByYW1kaXNrOiAw MDAwMDAwZmVhZjA1MDAwLT4wMDAwMDAwZmVlMWZmMjhlCihYRU4pIFZJUlRVQUwgTUVNT1JZIEFS UkFOR0VNRU5UOgooWEVOKSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MTAwMDAwMC0+ZmZmZmZm ZmY4NGEwMDAwMAooWEVOKSAgUGh5cy1NYWNoIG1hcDogMDAwMDAwODAwMDAwMDAwMC0+MDAwMDAw ODAwN2MxODUzOAooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4NGEwMDAwMC0+ZmZmZmZm ZmY4NGEwMDRiOAooWEVOKSAgUGFnZSB0YWJsZXM6ICAgZmZmZmZmZmY4NGEwMTAwMC0+ZmZmZmZm ZmY4NGEyYTAwMAooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NGEyYTAwMC0+ZmZmZmZm ZmY4NGEyYjAwMAooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAwMDAwMC0+ZmZmZmZm ZmY4NGMwMDAwMAooWEVOKSAgRU5UUlkgQUREUkVTUzogZmZmZmZmZmY4M2FlNzRjMAooWEVOKSBE b20wIGhhcyBtYXhpbXVtIDE2IFZDUFVzCihYRU4pIEluaXRpYWwgbG93IG1lbW9yeSB2aXJxIHRo cmVzaG9sZCBzZXQgYXQgMHg0MDAwIHBhZ2VzLgooWEVOKSBTY3J1YmJpbmcgRnJlZSBSQU0gaW4g YmFja2dyb3VuZAooWEVOKSBTdGQuIExvZ2xldmVsOiBFcnJvcnMsIHdhcm5pbmdzIGFuZCBpbmZv CihYRU4pIEd1ZXN0IExvZ2xldmVsOiBOb3RoaW5nIChSYXRlLWxpbWl0ZWQ6IEVycm9ycyBhbmQg d2FybmluZ3MpCihYRU4pIFhlbiBpcyByZWxpbnF1aXNoaW5nIFZHQSBjb25zb2xlLgooWEVOKSAq KiogU2VyaWFsIGlucHV0IHRvIERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dp dGNoIGlucHV0KQooWEVOKSBGcmVlZCA2NDhrQiBpbml0IG1lbW9yeQo= --b1_GBYj6Y1YZQCBAVgd6bUn1cquVDPuaNM7JB5U3PQFQw-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:07:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:07:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674489.1049446 (Exim 4.92) (envelope-from ) id 1rVYfQ-00028X-91; Thu, 01 Feb 2024 15:07:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674489.1049446; Thu, 01 Feb 2024 15: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 1rVYfQ-00028Q-5y; Thu, 01 Feb 2024 15:07:52 +0000 Received: by outflank-mailman (input) for mailman id 674489; Thu, 01 Feb 2024 15:07: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 1rVYfP-0001qg-At for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:07:51 +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 aa79f84a-c113-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 16:07:50 +0100 (CET) Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-40fc2a6f8b6so2487435e9.2 for ; Thu, 01 Feb 2024 07:07:50 -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 f6-20020a05600c154600b0040fa661ee82sm4733650wmg.44.2024.02.01.07.07.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 07:07: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: aa79f84a-c113-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706800070; x=1707404870; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nGJOcsAA00gDsEgOJ9ltZg1lwRc3fMEvRczR2WdI3fY=; b=l7HlO8tWaXBdYQDEjildnw29gx76kmOqCi51aMYTn3bpAYLxYfsmdgJceSUgZfW8+r cyVUPryQpXKmdQanJEXk8NyR0g/DG5OeJTptlm4gOs/9uaMHNTJNCy7wL4dPvsmGMoKz s88hl8NHJpS1thtedwPmRB+5zalgWCQLEhoJU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706800070; x=1707404870; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nGJOcsAA00gDsEgOJ9ltZg1lwRc3fMEvRczR2WdI3fY=; b=tD8/bx3hbUFrypJ8IGfHhPQm22JxNMAtjPC++czkInI+KajXnSzyx+d5q/TU9X7VQ0 kl1eBUQyhdeQIY5JeqTNiqU00z/qNDGJn446h2NFwxjsftLhPqS0yODaV7pLDWbcXqzv 1mlIcnrDPKjOZVod0EaOQeCCNtLZrARoA0cnsJ20pSBd8nEymJdzpBvbOpnJkXn4eOe8 w2UewuMaccxDOfRBtHVl/ucQ6H8rXdAC+HbuTX19eUPzXpPDlVHdDtcG9tx29qeZQl8G EHYTxX52I8Vf6zpIFNgNkM5MOXdiJh+sKUeWwIOwj1mgwFdyaTtKkBpH5HM61/EvXHu2 +HxA== X-Gm-Message-State: AOJu0YzSADe0ENSnmQx+DIoNRayGt6RY1bjcjw6ftctTh69o8Yp2VG7u kdWXbdJYSEQGrchd2Gyem1/mrrnW0s6cEqBKmsh/cWomO4b7rUvMCVa0/wB0Hm0= X-Google-Smtp-Source: AGHT+IHi1WXIrQV39Nw64NCPfXhk+pvoJVXXgdn0MTzRkbB2glhoZ880ndtYAmDlt1txv+rocLiSFg== X-Received: by 2002:a05:600c:5612:b0:40e:5ed3:ccf4 with SMTP id jr18-20020a05600c561200b0040e5ed3ccf4mr4677446wmb.16.1706800069963; Thu, 01 Feb 2024 07:07:49 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXP4Tu5Jw/IzHJ412fbg0giCN7S6+RIp4f1KngV8xCvhTjyypRdB4OeKw3ZyvPtN3xaCAmgEli6fj8JzB3xCeC2K5TO5Eo0iWA= Message-ID: Date: Thu, 1 Feb 2024 15:07:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fix some typos in comments Content-Language: en-GB To: Frediano Ziglio , George Dunlap Cc: xen-devel@lists.xenproject.org References: <20240201145943.738531-1-frediano.ziglio@cloud.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: <20240201145943.738531-1-frediano.ziglio@cloud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 01/02/2024 2:59 pm, Frediano Ziglio wrote: > Signed-off-by: Frediano Ziglio > --- > arch/x86/include/arch/processor.h | 2 +- > include/xen/hvm/params.h | 2 +- > include/xtf/console.h | 2 +- > include/xtf/extable.h | 4 ++-- > 4 files changed, 5 insertions(+), 5 deletions(-) This looks like an XTF patch? Considering that I do try to remember to spell check before committing, I'm somewhat embarrassed by this. ~Andrew From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:10:53 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:10:53 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674494.1049456 (Exim 4.92) (envelope-from ) id 1rVYiH-0003sc-Lv; Thu, 01 Feb 2024 15:10:49 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674494.1049456; Thu, 01 Feb 2024 15:10: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 1rVYiH-0003sV-JE; Thu, 01 Feb 2024 15:10:49 +0000 Received: by outflank-mailman (input) for mailman id 674494; Thu, 01 Feb 2024 15: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 1rVYiG-0003sL-Kw for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:10: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 13586c00-c114-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 16:10:46 +0100 (CET) Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-556c3f0d6c5so1263139a12.2 for ; Thu, 01 Feb 2024 07:10:46 -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 fi7-20020a170906da0700b00a36edfb508asm15809ejb.79.2024.02.01.07.10.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 07:10: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: 13586c00-c114-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706800246; x=1707405046; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MpmtCMKIg7MG7KLzATLN7tvHdDRolI1j9YpQuU+oSQU=; b=aRqfkYsJs+etBmF9yFOy6h8zA1aQzCv/EcB3MOG8YiM3uDwvV0eis5dKYd0yk030Mn tuEbsRTgDLWHRPF8ziPQmfv+DQYIIXtAi/rR2oYUJ7abm0I28c6qUy6g7vhDMxBJWw/V R0xKIYLbq1D6DNhlz+MxdCmfOcF6BCOdOSB+mhMraugoDVF4HXMeX9O2BEIROo0Nctbr HI1JNfuW8QnDxZrRBbz+GcKLjp0/klevlZsN3b8FoMpBlJQ6oZ/XkQAUm1KfiRQ2QJSR wAC7Q0GR4DSBP5MI/BfJzdTCcbJtx1Rq3zGan3138biKTcmtiiIW4v57LZxJdQXTJr+4 0fbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706800246; x=1707405046; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MpmtCMKIg7MG7KLzATLN7tvHdDRolI1j9YpQuU+oSQU=; b=nyVNdg7VFP74R2tCjnMTaapOygPGL0dtEr5A87bcH8q5vsT8cl/cLIzPSKSl+USjwx YkNtA0kkCvUA6SNArGnBscyD5qzOVA2G+x9k1oA1C8jzA86TzgQu3ZDFQwgWs2LFuAwl XOJS1Zs9kHHaAaPgflIsyrlxd3Ibmv40OVqTG/tF4jkSBv66As7OXRYgX70itm4rPLUu 26UrDO2StIR+bdnyC48aER/mTnEuJkWqEEHk8ND0Bln/yIo1NHxxPdOeJYColdShRqTC AWjL7bpe/IT4iDXGKu9G2MSqtsF1F2xTlFdeltunjftkz5NXtlK8pJ2lsvgdXksxDyjD C60A== X-Gm-Message-State: AOJu0YyuH9adlzYjfJiGN3ech3DId3HIt1OSO5Pe3NkusEYkPKUoNiUS XjQjo7C9A4frQbBqLzOiTcw9b1OjR+cOiO6vM2dXJrDAhsfKdnChFJMxyLSSSQ== X-Google-Smtp-Source: AGHT+IFEpnKZ6B3Px3BJI0czRwgs70itxp5h5od8ByQw4MCMAbS+fVkWAyW/nE6DxqtxJDLUmYl4+Q== X-Received: by 2002:a17:906:c7d2:b0:a36:9f72:2461 with SMTP id dc18-20020a170906c7d200b00a369f722461mr1894807ejb.69.1706800245952; Thu, 01 Feb 2024 07:10:45 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUzfX2oWSfXNYZuvfUjh+pvznlFpyEUpMiT0WSDrvE8dnVPoAMp3WPZtAMOoNSQS7LmXJ/EF1CCBpmzXbZf3NkMmHsFJAt7rMEgA4X2HU2h6sD1BVo66/y7DFAf18k2gEDLWCS2Qzby1Nr3kunL7Y4J0tDGwkVQSFfmkV/BPaCBX5+fC+pI4kg5SEWFSThBoH/vzRlIjdV7leLV30skF96fu1+TSn2qpIHFsT0TAhchgVf00Mwb+WSYJtOxOrWuvwrrkkoPOgk1gJmvuooptMY/welzze3JbzRjSZ0At3jRSG09y/gvQbDvLcUu Message-ID: Date: Thu, 1 Feb 2024 16:10:44 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 12/15] xen/arm: add Xen cache colors command line parameter Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Luca Miccio , Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-13-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > --- a/xen/common/llc-coloring.c > +++ b/xen/common/llc-coloring.c > @@ -9,6 +9,9 @@ > #include > #include > > +#define XEN_DEFAULT_COLOR 0 > +#define XEN_DEFAULT_NUM_COLORS 1 > + > bool __ro_after_init llc_coloring_enabled; > boolean_param("llc-coloring", llc_coloring_enabled); > > @@ -21,6 +24,9 @@ static unsigned int __ro_after_init max_nr_colors = CONFIG_NR_LLC_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]; So unlike for Dom0 here you use the static buffer at runtime. > +static unsigned int __ro_after_init xen_num_colors; Taken together, I don't see the value in having XEN_DEFAULT_COLOR: One can't simply change it and XEN_DEFAULT_NUM_COLORS to have Xen have, say, 4 colors by default. I think you want to have xen_colors[] have an initializer, with XEN_DEFAULT_COLOR dropped and XEN_DEFAULT_NUM_COLORS moved. Or you actually allocate the runtime buffer if a command line option is found, and just use ARRAY_SIZE() as the default count. Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:14:02 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:14:02 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674501.1049466 (Exim 4.92) (envelope-from ) id 1rVYlK-0004lt-6d; Thu, 01 Feb 2024 15:13:58 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674501.1049466; Thu, 01 Feb 2024 15:13: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 1rVYlK-0004lm-3s; Thu, 01 Feb 2024 15:13:58 +0000 Received: by outflank-mailman (input) for mailman id 674501; Thu, 01 Feb 2024 15:13: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 1rVYlI-0004lb-FB for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:13:56 +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 840f4193-c114-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 16:13:55 +0100 (CET) Received: by mail-lj1-x232.google.com with SMTP id 38308e7fff4ca-2d051fb89fbso14707001fa.2 for ; Thu, 01 Feb 2024 07:13: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 fd12-20020a056402388c00b00557d839727esm6884848edb.7.2024.02.01.07.13.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 07:13: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: 840f4193-c114-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706800435; x=1707405235; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=aXKi7HcGOdYt1N8wDuA8yYqEyLVPLGkiW5x+mctbQnA=; b=bWkIisqtI5SzalPgEt5kCQ7YohYzKYzey2y5EKPQzdI4TmcfSk7Pm1rChK9jdqIZQS KVJc7PR3SQVxBggJUm59TqBUf5sPLow3leh86El51BpRRKdHSCvSHZ+OCb5l/QXUCgV8 JNfWAjoRdibA4PclPlMOgsTSJnSm+6gw+neHEsfH8ap999y5KO2c0mtJD6yv0bXS034A kA9uH2jPS5qOaZiVP1TbgNjduI9kKrU83lelUBydZfEtwPCsSioY1h2Dgtteg5oGzgHb CIO2zOU5O5+CxcR4V3vK2PZdls2anfjYS3R4AM8X8oobWlQbRB/ispLWVu9LXb07SYrE TccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706800435; x=1707405235; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aXKi7HcGOdYt1N8wDuA8yYqEyLVPLGkiW5x+mctbQnA=; b=MUz7CIGyy3LJhuyH0jsr+2C/kIHzQHcPaNXZYrwhCu/tl+ICjiucP+FgpOEWCy8PhL MWoO5bCud2ex+ai6u4arHMXVEpGGQzJl+OO7cFCHFPJaI1WjRTA1DQud7cE2QD/tUQpC JgyggVXB0sFviGJipPA2llxP2+Sg6bj4qQkU/8lDfbcUc4f9etdz0ywweUt0KlGwboxQ R99lk4wA3skc6sVYGZ69S8pq69DHiajqwK2NlMI+qTNEgTYFsDo1d4tKs60FQsJfnugh +t29EGKh3fkbdrZjJpndye9/y3EVLLpG3EMXlA76O9Sfn5FI/1s3q2gr69v5Jn+My3Lz b06w== X-Gm-Message-State: AOJu0YwXec05dMGqoiVFRJ4eRWa3f+0W24HlAqEHhZ9WDwPGNSmTYxOd q+yfVTiwWFnXdXIb9rn1Kl5shxPTI2avACSfRVnczO+WVF7mp0z9CpWpp5lX1w== X-Google-Smtp-Source: AGHT+IEwSjCvoaggmdb4kXFYQ3RqVlua5qOImD5wc0V+Ei6g/Qsou0fiRFdsxrx/AZH+QvWRLeq67A== X-Received: by 2002:a2e:9858:0:b0:2d0:438d:fb2b with SMTP id e24-20020a2e9858000000b002d0438dfb2bmr3924988ljj.33.1706800434948; Thu, 01 Feb 2024 07:13:54 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXCnKVNGws8gZYP1EY2/PjY6v/uPpFtl6vBpS+NUH7YIylRcIrznKZsk39x9ci+NlSxlAgPIS01v9xRBuDifvM23uRKe+uP7rZN2W0MVQnREkGVJJQ0NuNRmqChVhrtl6q3tfWTvoLzR8r84dAFz0OQrgB/df9I4jdimor7gKgAp7GgTg10I/54TdqZaS76eT0t/PnZTx91S7FnK5py6w7YDBrqVomlnlrRuaxkOaHbhzqUE7uEGtw= Message-ID: <246c970c-7fad-4842-8305-bcee78a52843@suse.com> Date: Thu, 1 Feb 2024 16:13:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 09/15] xen/page_alloc: introduce preserved page flags macro Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-10-carlo.nonato@minervasys.tech> <8a3f3c38-b290-417a-86cb-216e36182abe@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 01.02.2024 15:49, Carlo Nonato wrote: > On Thu, Feb 1, 2024 at 3:24 PM Jan Beulich wrote: >> On 29.01.2024 18:18, Carlo Nonato wrote: >>> PGC_static and PGC_extra are flags that 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. >> >> While here you say where the "preserving" applies, ... >> >>> --- a/xen/common/page_alloc.c >>> +++ b/xen/common/page_alloc.c >>> @@ -157,6 +157,8 @@ >>> #define PGC_static 0 >>> #endif >>> >>> +#define PGC_preserved (PGC_extra | PGC_static) >> >> ... nothing is said here. From the earlier version I also seem to recall >> that the constant was then used outside of assign_pages(). That would >> then mean amending whatever comment would be added here. > > Yes, but it was used in places where the name didn't fit (to stop merging in > free_heap_pages()) and so I thought it would've been better to use the > constant only for one of the two concepts: only for preserved flags in > assign_pages(). > > Are you suggesting adding a comment to this #define to clarify its usage? Yes. Albeit if I understand the earlier paragraph right, you don't use it further (anymore). In which case the question would be: Is the patch still needed, and if so is it rightfully part of this series? Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:43:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:43:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674508.1049477 (Exim 4.92) (envelope-from ) id 1rVZDq-00062u-E9; Thu, 01 Feb 2024 15:43:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674508.1049477; Thu, 01 Feb 2024 15: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 1rVZDq-00062n-BM; Thu, 01 Feb 2024 15:43:26 +0000 Received: by outflank-mailman (input) for mailman id 674508; Thu, 01 Feb 2024 15: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 1rVZDp-00061u-Cu for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:43:25 +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 a240a512-c118-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 16:43:24 +0100 (CET) Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-40e76626170so9304235e9.2 for ; Thu, 01 Feb 2024 07:43:24 -0800 (PST) Received: from [10.95.167.50] (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id h12-20020a05600c260c00b0040d87100733sm4683354wma.39.2024.02.01.07.43.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 07:43: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: a240a512-c118-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706802203; x=1707407003; 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=g2UrnwlOgsItEDKTVLgJCkedsveuSTltHV+AVhMWfwo=; b=jMtTrhX8uL6LODSVrmT42juVnhrpOHZKIEYzr1QBh8NbFYFLffvQHgXbnHHTkJvh5l LLT+3EvTY4JbfLF9kyggyc7OYtXskXlzrPix2bDe2LJWeOf9cUb0eC7BFtqDPMz14yjH UgPy37X1YtM1wtPzalR9XRVlNWXSH6KwXAwQ4dpj5rlWIgUTCAcGeRM3tZ9vU8wmm40c 0eFNjg1RP+WFUU3Up56Tn8O+5godcbo0C1fQgOichHwMwgddn4ogam4xtpuqJepvGm3l frpbswWLyBFz0OZF/R+mltBBL+sEPHmMnA5AETEnnMM1kItLK6W9+5VzYbdhc1pRgyY9 eq5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706802203; x=1707407003; 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=g2UrnwlOgsItEDKTVLgJCkedsveuSTltHV+AVhMWfwo=; b=pAw/gdwY1Zge1C395g9s1uxPrWs7gfLCsn5XhBCQkhznRI4EshW3EAxSlYVig1Nn4l U9Sewp6JHnimMYwe7LGlGbYc+oIqNbAmESzsfGc7xMrF74ZcAkMKeGSfe0AxBnf0j+EC Z9IPJq0enkK8AvgIdnu3Vb17rA9KccpvCn+rSG+1iPZA/JwOfY3jZ2N0CUZ2WxNTCWMS EepNZXKunqEpoaipcfWMnTbsjws9QRkublNQUavqTTMo8OPESqxakIEZ5lFJXm82JtP0 qSPzTFdZyV3Y6Qk4Lo80ogeIi+X+XanF8kecRRgdxvmv8B0/z8wdXjlBcX28Noslvewd 5ksQ== X-Gm-Message-State: AOJu0YyYwUS/5G4CikH+zb12YVm6e6PM5vUTKvO4Fjj8FY9/2zIbnqUN MxZN4/nypod84iWuO0mvYGS4cPQxo/6EkxBpKLqSGLLY4nsNP1P2 X-Google-Smtp-Source: AGHT+IGwEQbXnJ24dLKwBX9KdAuPoFpCEhwu8WSK1M5x2HdTKaFyDg5C3nBYtavqD107Kr1ecR86Gg== X-Received: by 2002:a5d:440b:0:b0:33b:182f:eb9d with SMTP id z11-20020a5d440b000000b0033b182feb9dmr1261356wrq.43.1706802203356; Thu, 01 Feb 2024 07:43:23 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWhQorHyBHjSUpH8dxTdPXUf5nO8Z9/mt5FVm88AJruzfba5njDn7SvUjQAgNPuU7tlZqD0U5nA3VizSmFmtAhGM9Ry5S8SuJSInCWFV5UlbgMbv8KnpMdlcRXnteE3NnhGPS4NFlly26oaQtBBnbptkRA= From: Paul Durrant X-Google-Original-From: Paul Durrant Message-ID: Date: Thu, 1 Feb 2024 15:43:21 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: paul@xen.org Subject: Re: [PATCH net] xen-netback: properly sync TX responses To: Jakub Kicinski Cc: Jan Beulich , "netdev@vger.kernel.org" , Wei Liu , "xen-devel@lists.xenproject.org" References: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> <20240131162336.7d3ba09e@kernel.org> Content-Language: en-US Organization: Xen Project In-Reply-To: <20240131162336.7d3ba09e@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 01/02/2024 00:23, Jakub Kicinski wrote: > On Mon, 29 Jan 2024 14:03:08 +0100 Jan Beulich wrote: >> Invoking the make_tx_response() / push_tx_responses() pair with no lock >> held would be acceptable only if all such invocations happened from the >> same context (NAPI instance or dealloc thread). Since this isn't the >> case, and since the interface "spec" also doesn't demand that multicast >> operations may only be performed with no in-flight transmits, >> MCAST_{ADD,DEL} processing also needs to acquire the response lock >> around the invocations. >> >> To prevent similar mistakes going forward, "downgrade" the present >> functions to private helpers of just the two remaining ones using them >> directly, with no forward declarations anymore. This involves renaming >> what so far was make_tx_response(), for the new function of that name >> to serve the new (wrapper) purpose. >> >> While there, >> - constify the txp parameters, >> - correct xenvif_idx_release()'s status parameter's type, >> - rename {,_}make_tx_response()'s status parameters for consistency with >> xenvif_idx_release()'s. > > Hi Paul, is this one on your TODO list to review or should > we do our best? :) Sorry for the delay. I'll take a look at this now. Paul From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:44:22 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:44:22 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674510.1049487 (Exim 4.92) (envelope-from ) id 1rVZEj-0006XT-NR; Thu, 01 Feb 2024 15:44:21 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674510.1049487; Thu, 01 Feb 2024 15:44: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 1rVZEj-0006XM-Ki; Thu, 01 Feb 2024 15:44:21 +0000 Received: by outflank-mailman (input) for mailman id 674510; Thu, 01 Feb 2024 15:44:20 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVZEi-0006X2-4B; Thu, 01 Feb 2024 15:44: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 1rVZEi-0003UO-35; Thu, 01 Feb 2024 15:44: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 1rVZEh-0001aI-Gl; Thu, 01 Feb 2024 15:44:19 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rVZEh-0000pg-GJ; Thu, 01 Feb 2024 15:44: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=jrPTGdghm9eLsf7XVixHjPJv1bXKsmFnKpgqmiZKISA=; b=dLc/vBNMEtgz/ybT5ItLDFPy8B DwrIfy011kKW7FjBaNkJPR3GdMIZ2TK9kHJO9d21jPsYuBCBPFQSxFKaN109FurcinZ8oF/CtPX4x pY3Mknlvl52rhrDeRthL+RCxhdI9Mvi4/EBWSocWOCuVhkGUgpKSUQ4GZwzmMZqhmzTs=; To: xen-devel@lists.xenproject.org Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Subject: [libvirt test] 184548: regressions - FAIL X-Osstest-Failures: libvirt:build-arm64-libvirt:libvirt-build:fail:regression libvirt:test-arm64-arm64-libvirt:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-qcow2:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-raw:build-check(1):blocked:nonblocking libvirt:test-arm64-arm64-libvirt-xsm:build-check(1):blocked:nonblocking libvirt:test-armhf-armhf-libvirt:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-qcow2:saverestore-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:saverestore-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-vhd:migrate-support-check:fail:nonblocking libvirt:test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm:migrate-support-check:fail:nonblocking libvirt:test-amd64-i386-libvirt-raw:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-qcow2:migrate-support-check:fail:nonblocking libvirt:test-armhf-armhf-libvirt-raw:migrate-support-check:fail:nonblocking X-Osstest-Versions-This: libvirt=f85a382a0e709afea3a4021de593b1679553a35a X-Osstest-Versions-That: libvirt=2757e91c2b28b704d9a0b586fb60012450110b1a From: osstest service owner Date: Thu, 01 Feb 2024 15:44:19 +0000 flight 184548 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/184548/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-build fail REGR. vs. 184537 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184537 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184537 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184537 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-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-armhf-armhf-libvirt 15 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 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-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: libvirt f85a382a0e709afea3a4021de593b1679553a35a baseline version: libvirt 2757e91c2b28b704d9a0b586fb60012450110b1a Last test of basis 184537 2024-01-31 04:24:45 Z 1 days Testing same since 184548 2024-02-01 06:57:31 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani Göran Uddeborg Peter Krempa Stefano Brivio 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 fail 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-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-qcow2 pass test-arm64-arm64-libvirt-raw blocked test-armhf-armhf-libvirt-raw pass test-amd64-i386-libvirt-raw pass test-amd64-amd64-libvirt-vhd pass ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these 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 582 lines long.) From xen-devel-bounces@lists.xenproject.org Thu Feb 01 15:53:24 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 15:53:24 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674519.1049500 (Exim 4.92) (envelope-from ) id 1rVZNM-00013m-Ju; Thu, 01 Feb 2024 15:53:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674519.1049500; Thu, 01 Feb 2024 15: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 1rVZNM-000133-Gn; Thu, 01 Feb 2024 15:53:16 +0000 Received: by outflank-mailman (input) for mailman id 674519; Thu, 01 Feb 2024 15:53: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 1rVZNL-00012x-PD for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 15:53:15 +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 016915aa-c11a-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 16:53:13 +0100 (CET) Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-a3566c0309fso145167566b.1 for ; Thu, 01 Feb 2024 07:53: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 bv11-20020a170906b1cb00b00a35e7326b69sm3832284ejb.93.2024.02.01.07.53.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 07:53: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: 016915aa-c11a-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1706802793; x=1707407593; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jnPQD2HqisVQvijjQ142klgke++wMuogZ1JRlvcJlRI=; b=KSw0As6M4LuqAuqCalTNb85ZhTpEDUtYhaZxsFwdq40HnXqWueRnQb9CxMhUT6AqBD 2ly67y400kTJ1qdJnsVTQTezO4gBDXcq/Po+vNGHzVvbMP0+Mf+CDA7NGcEAfpapUHMN CYPxygi3GqFsRGZZP/7qMFdqSJjUMDSvVrwidMGwniwuNbzcBf1h6gLArFGT/g2hUB3a rRbk2vzCwIApEd1Jd9OOwKp/4ES9q6AIJlwg+juyGcl0G/DcSAFZ0vXHicuXx8vgylHp +kERuB6AvhsphDi0lIAeFvGsfC0i/5/flhofWyAW2LKAgMphJWYObwepMt3/GiQJtFNk vcSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706802793; x=1707407593; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jnPQD2HqisVQvijjQ142klgke++wMuogZ1JRlvcJlRI=; b=QT8FzUJFumOuy1vZUa4aH2EB9LfWb1V1p2yEwGESU5Gncd0FuYr4tQRiKmhdSywzMZ KEfxnc85AZ+/TNSwwcCf6FvmOV2PQ6nHskqC/gulBSjcvhE2qzLHVV16mi5gH65jWVxJ cg4XzY2AiKxlscX7GjZesIFOIdMWRxkQEaTrCgbybcwfAyucSuIa/3v1dDpOoOzn+dGI wAjYiotOXU+UlqSCyF5+WBGr6PUwbJEg0vDeDWTZotm1fgs1fTGsEY92ke6nhVo17Z7e erB88hsdcAaJw5KeoJuX2wzj38FpFA4Plefa/uz9+5SJE4JcF+zpLVUfypm3LoIusIgp jPcg== X-Gm-Message-State: AOJu0YylagojWQBpM1g0c27zhwZ15EkmKIW83rXqSfq8Ae6Px5sN8oK1 /DU4J5SZbL9TC/nh8MnlrSgwNS2qUzNins/WM+fJInNlVK0lh4JPrYelLKFvpA== X-Google-Smtp-Source: AGHT+IH5atcEZv0GpexmtmtfD2kn1bhOvJUNo+K8fd1EjAJFL1oU1YyrgFAn8+Z45/5Y8avjunghSQ== X-Received: by 2002:a17:906:e9a:b0:a2d:a6a7:b3bc with SMTP id p26-20020a1709060e9a00b00a2da6a7b3bcmr3386227ejf.4.1706802792683; Thu, 01 Feb 2024 07:53:12 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCURc03naErdxIlak0VCqU9q9pK521sr8P/KDp0LC80O9mFYeQnumZLLigpWFcDJX7+Np7FQcVsgiur4aLUunfU+TtrFUlA50TCdpJWtiTv5UMWEFvqzQhotj4VH2k8EFwHjqz2fD/IqCXPPdo/MbIWN6Q1IEzVoFf02rJfkaezF/Uel1ktroSg5AnLcCyZk6XFKJu5yw3laaVAaVyCzYXFSalw8X0M02CuxY637CnmPKcIo0YvrzEJNrHGiyD2suXVkhnaHCB24rAOt03auaIE9L0oWiX1lI6Xh46FLsvyRKFgYg5XlSqrLBIoIM+JowAyzmJPWtUTwnnEXeII/7LdSPuqOIl5f4jFaSNZx+5/oJpCeackIqZgv1LZsdF+41Um2JQ== Message-ID: <1739dbb4-5d7e-4d84-8d4b-bfb13c4041d8@suse.com> Date: Thu, 1 Feb 2024 16:53:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 10/15] xen: add cache coloring allocator for domains Content-Language: en-US To: Carlo Nonato Cc: andrea.bastoni@minervasys.tech, Andrew Cooper , George Dunlap , Julien Grall , Stefano Stabellini , Wei Liu , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Marco Solieri , xen-devel@lists.xenproject.org References: <20240129171811.21382-1-carlo.nonato@minervasys.tech> <20240129171811.21382-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: <20240129171811.21382-11-carlo.nonato@minervasys.tech> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 29.01.2024 18:18, Carlo Nonato wrote: > @@ -157,7 +158,11 @@ > #define PGC_static 0 > #endif > > -#define PGC_preserved (PGC_extra | PGC_static) > +#ifndef PGC_colored > +#define PGC_colored 0 > +#endif > + > +#define PGC_preserved (PGC_extra | PGC_static | PGC_colored) > > #ifndef PGT_TYPE_INFO_INITIALIZER > #define PGT_TYPE_INFO_INITIALIZER 0 > @@ -1504,6 +1509,7 @@ static void free_heap_pages( > if ( !mfn_valid(page_to_mfn(predecessor)) || > !page_state_is(predecessor, free) || > (predecessor->count_info & PGC_static) || > + (predecessor->count_info & PGC_colored) || How about a 2nd #define (e.g. PGC_no_buddy_merge) to use here and ... > (PFN_ORDER(predecessor) != order) || > (page_to_nid(predecessor) != node) ) > break; > @@ -1528,6 +1534,7 @@ static void free_heap_pages( > if ( !mfn_valid(page_to_mfn(successor)) || > !page_state_is(successor, free) || > (successor->count_info & PGC_static) || > + (successor->count_info & PGC_colored) || ... here? That'll then also avoid me commenting that I don't see why these two PGC_* checks aren't folded. > @@ -1943,6 +1950,161 @@ 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; > +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)] Nit: Unnecessary parentheses inside the square brackets. > +#else > +static unsigned long __initdata buddy_alloc_size; > + > +#define domain_num_llc_colors(d) 0 > +#define domain_llc_color(d, i) 0 > +#endif > + > +#define color_heap(color) (&_color_heap[color]) Wouldn't this better live next to _color_heap()'s definition? > +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); > + } > + > + pg->count_info |= PGC_colored; The page transiently losing PGC_colored is not an issue then (presumably because of holding the heap lock)? Did you consider having mark_page_free() also use PGC_preserved? > + 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 scrub = !(memflags & MEMF_no_scrub); > + > + 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; > + } > + } The apporach is likely fine at least initially, but: By going from where the most free pages are, you're not necessarily evenly distributing a domain's pages over the colors it may use, unless the domain uses its set of colors exclusively. > + if ( !pg ) > + { > + spin_unlock(&heap_lock); > + return NULL; > + } > + > + pg->count_info = PGC_state_inuse | PGC_colored | > + (pg->count_info & PGC_need_scrub); Isn't PGC_colored already set on the page? Together with ... > + 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 ( test_and_clear_bit(_PGC_need_scrub, &pg->count_info) && scrub ) ... this, can't the above be simplified? > + scrub_one_page(pg); > + else if ( scrub ) > + 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)); > + } > + > + if ( nr_pages ) > + printk(XENLOG_DEBUG > + "Init color heap with %lu pages, start MFN: %"PRI_mfn"\n", > + nr_pages, mfn_x(page_to_mfn(pg))); This message can be issued more than once. Is that really desirable / necessary? > @@ -2458,7 +2626,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; > + } I think I had asked before: What about MEMF_node() or MEMF_bits() having been used by the caller? Jan From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:10:43 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:10:43 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674524.1049510 (Exim 4.92) (envelope-from ) id 1rVZdz-0006IS-4i; Thu, 01 Feb 2024 16:10:27 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674524.1049510; Thu, 01 Feb 2024 16:10: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 1rVZdz-0006IL-1z; Thu, 01 Feb 2024 16:10:27 +0000 Received: by outflank-mailman (input) for mailman id 674524; Thu, 01 Feb 2024 16: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 1rVZdx-0006IF-KU for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:10:25 +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 67de5e1c-c11c-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 17:10:24 +0100 (CET) Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-33b1b21c020so260087f8f.0 for ; Thu, 01 Feb 2024 08:10:24 -0800 (PST) Received: from [10.95.167.50] (54-240-197-233.amazon.com. [54.240.197.233]) by smtp.gmail.com with ESMTPSA id a15-20020a056000100f00b0033aee3bfac5sm10679554wrx.16.2024.02.01.08.10.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Feb 2024 08:10: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: 67de5e1c-c11c-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706803823; x=1707408623; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :content-language:subject:reply-to:user-agent:mime-version:date :message-id:from:from:to:cc:subject:date:message-id:reply-to; bh=yvgKt6vyIvLQ9cao7dV112oZw/spOoZQuBNAwiuVdb8=; b=iurUL+SnHD4LNJg78ueat7VSRM0I27B6HsnDT4SEJIvxH/PEv8RIELZIYHnuUvGBaU YFFiBb/Z/xNcS+qdHxOKYff2cnRIrmRdrLNqENNExQZduFsVAXq2hRLO22h+4p7itKVn 5MlB1xjVGSBfXa48azbKEjfHtDp0tgga+bdFgxemtZWQZifD+Gw4ytr7T4TCO6/SKDN6 mFIiK1NjcQA89/n+p/9H4cQ28JYYdqheFlGQyO05Lk2AF2u65qXE86p5xpJg1fArF/3P O2U/z0SuXL2wER7QRyS66Ewg6uwXZLFzSLDKPrbV/Zfh2MI6YqNyt+d4ueB76Uc6PTcs amoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706803823; x=1707408623; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :content-language: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=yvgKt6vyIvLQ9cao7dV112oZw/spOoZQuBNAwiuVdb8=; b=XaiKaafrnVbYZY6CA9euQViexG+uGRvYyct9tw5kc3bq3txlnD04uh9rgsyMMPjMnd Ad8BPqCKssprXAP1FC7gYl7rzrGceldlwN0UOYneiFKfV0mGGhQlW3+fGVOn0ljz/hbG oL3rk4lw0sF8yqHMDBKoj5T+Ly4QhxeONJMAC6pwWTKfmB3AN6HP2WS/ciryTd/Gm4Cj CN4/n3ZgBLiIJEvReITa79OnMtVoAO18kHlB1c1AXLCMs0GPegdv0k/XIVHptV/G699t Bhwxwck2ZqHLba2D+f5tGVzb0Gg/rR1aOvbwtc5IDpOQwpMMW7uxgjVN/qk7hNR3xJWv Mu7g== X-Gm-Message-State: AOJu0Yy+BVmpc+Uxt/lp+seeBQ2gUYq4mLDXg8juS+fn6ZqyQMFfiVuN U7NDeONnhjhvNauhRcqaTyTRQjhKgSRDS3JNNFi6M6tvOICuuxln X-Google-Smtp-Source: AGHT+IEJ1m79KnyLHr6GvYPcIVi1Yn5A5Nr4MDBCO78RLOXhhcFiwoz/B1H/xeAutDcnO1f9DXmivw== X-Received: by 2002:a5d:6b81:0:b0:33a:fec8:e46a with SMTP id n1-20020a5d6b81000000b0033afec8e46amr4267477wrx.11.1706803823477; Thu, 01 Feb 2024 08:10:23 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCViOqOOszIhKkGMgLBmqB92mrQNRdR7OnPceOL0Z9LSVRHf4dJA9gJwG7JBTlRP94BQ48gsy/QsdPjZgPY6BhSE176aU/sPB+whQerq9g1p2xjSj4t+4gumT/sTyp1gCIf9yoShBiM= From: Paul Durrant X-Google-Original-From: Paul Durrant Message-ID: <383c1d4a-175f-4e23-b884-b9d9c1dce4da@xen.org> Date: Thu, 1 Feb 2024 16:10:19 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: paul@xen.org Subject: Re: [PATCH net] xen-netback: properly sync TX responses Content-Language: en-US To: Jan Beulich , "netdev@vger.kernel.org" Cc: Wei Liu , "xen-devel@lists.xenproject.org" References: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> Organization: Xen Project In-Reply-To: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 29/01/2024 13:03, Jan Beulich wrote: > Invoking the make_tx_response() / push_tx_responses() pair with no lock > held would be acceptable only if all such invocations happened from the > same context (NAPI instance or dealloc thread). Since this isn't the > case, and since the interface "spec" also doesn't demand that multicast > operations may only be performed with no in-flight transmits, > MCAST_{ADD,DEL} processing also needs to acquire the response lock > around the invocations. > > To prevent similar mistakes going forward, "downgrade" the present > functions to private helpers of just the two remaining ones using them > directly, with no forward declarations anymore. This involves renaming > what so far was make_tx_response(), for the new function of that name > to serve the new (wrapper) purpose. > > While there, > - constify the txp parameters, > - correct xenvif_idx_release()'s status parameter's type, > - rename {,_}make_tx_response()'s status parameters for consistency with > xenvif_idx_release()'s. > > Fixes: 210c34dcd8d9 ("xen-netback: add support for multicast control") > Cc: stable@vger.kernel.org > Signed-off-by: Jan Beulich > --- > Of course this could be split into two or even more separate changes, > but I think these transformations are best done all in one go. > > It remains questionable whether push_tx_responses() really needs > invoking after every single _make_tx_response(). > > MCAST_{ADD,DEL} are odd also from another perspective: They're supposed > to come with "dummy requests", with the comment in the public header > leaving open what that means. IIRC the only reference I had at the time was Solaris code... I don't really there being any documentation of the feature. I think that https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/xen/io/xnb.c is probably similar to the code I looked at to determine what the Solaris frontend expected. So I think 'dummy' means 'ignored'. > Netback doesn't check dummy-ness (e.g. > size being zero). Furthermore the description in the public header > doesn't really make clear that there's a restriction of one such "extra" > per dummy request. Yet the way xenvif_get_extras() works precludes > multiple ADDs or multiple DELs in a single dummy request (only the last > one would be honored afaict). While the way xenvif_tx_build_gops() works > precludes an ADD and a DEL coming together in a single dummy request > (the DEL would be ignored). It appears the Solaris backend never coped with multiple extra_info so what the 'correct' semantic would be is unclear. Anyway... Reviewed-by: Paul Durrant > > --- a/drivers/net/xen-netback/netback.c > +++ b/drivers/net/xen-netback/netback.c > @@ -104,13 +104,12 @@ bool provides_xdp_headroom = true; > module_param(provides_xdp_headroom, bool, 0644); > > static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx, > - u8 status); > + s8 status); > > static void make_tx_response(struct xenvif_queue *queue, > - struct xen_netif_tx_request *txp, > + const struct xen_netif_tx_request *txp, > unsigned int extra_count, > - s8 st); > -static void push_tx_responses(struct xenvif_queue *queue); > + s8 status); > > static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx); > > @@ -208,13 +207,9 @@ static void xenvif_tx_err(struct xenvif_ > unsigned int extra_count, RING_IDX end) > { > RING_IDX cons = queue->tx.req_cons; > - unsigned long flags; > > do { > - spin_lock_irqsave(&queue->response_lock, flags); > make_tx_response(queue, txp, extra_count, XEN_NETIF_RSP_ERROR); > - push_tx_responses(queue); > - spin_unlock_irqrestore(&queue->response_lock, flags); > if (cons == end) > break; > RING_COPY_REQUEST(&queue->tx, cons++, txp); > @@ -465,12 +460,7 @@ static void xenvif_get_requests(struct x > for (shinfo->nr_frags = 0; nr_slots > 0 && shinfo->nr_frags < MAX_SKB_FRAGS; > nr_slots--) { > if (unlikely(!txp->size)) { > - unsigned long flags; > - > - spin_lock_irqsave(&queue->response_lock, flags); > make_tx_response(queue, txp, 0, XEN_NETIF_RSP_OKAY); > - push_tx_responses(queue); > - spin_unlock_irqrestore(&queue->response_lock, flags); > ++txp; > continue; > } > @@ -496,14 +486,8 @@ static void xenvif_get_requests(struct x > > for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; ++txp) { > if (unlikely(!txp->size)) { > - unsigned long flags; > - > - spin_lock_irqsave(&queue->response_lock, flags); > make_tx_response(queue, txp, 0, > XEN_NETIF_RSP_OKAY); > - push_tx_responses(queue); > - spin_unlock_irqrestore(&queue->response_lock, > - flags); > continue; > } > > @@ -995,7 +979,6 @@ static void xenvif_tx_build_gops(struct > (ret == 0) ? > XEN_NETIF_RSP_OKAY : > XEN_NETIF_RSP_ERROR); > - push_tx_responses(queue); > continue; > } > > @@ -1007,7 +990,6 @@ static void xenvif_tx_build_gops(struct > > make_tx_response(queue, &txreq, extra_count, > XEN_NETIF_RSP_OKAY); > - push_tx_responses(queue); > continue; > } > > @@ -1433,8 +1415,35 @@ int xenvif_tx_action(struct xenvif_queue > return work_done; > } > > +static void _make_tx_response(struct xenvif_queue *queue, > + const struct xen_netif_tx_request *txp, > + unsigned int extra_count, > + s8 status) > +{ > + RING_IDX i = queue->tx.rsp_prod_pvt; > + struct xen_netif_tx_response *resp; > + > + resp = RING_GET_RESPONSE(&queue->tx, i); > + resp->id = txp->id; > + resp->status = status; > + > + while (extra_count-- != 0) > + RING_GET_RESPONSE(&queue->tx, ++i)->status = XEN_NETIF_RSP_NULL; > + > + queue->tx.rsp_prod_pvt = ++i; > +} > + > +static void push_tx_responses(struct xenvif_queue *queue) > +{ > + int notify; > + > + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&queue->tx, notify); > + if (notify) > + notify_remote_via_irq(queue->tx_irq); > +} > + > static void xenvif_idx_release(struct xenvif_queue *queue, u16 pending_idx, > - u8 status) > + s8 status) > { > struct pending_tx_info *pending_tx_info; > pending_ring_idx_t index; > @@ -1444,8 +1453,8 @@ static void xenvif_idx_release(struct xe > > spin_lock_irqsave(&queue->response_lock, flags); > > - make_tx_response(queue, &pending_tx_info->req, > - pending_tx_info->extra_count, status); > + _make_tx_response(queue, &pending_tx_info->req, > + pending_tx_info->extra_count, status); > > /* Release the pending index before pusing the Tx response so > * its available before a new Tx request is pushed by the > @@ -1459,32 +1468,19 @@ static void xenvif_idx_release(struct xe > spin_unlock_irqrestore(&queue->response_lock, flags); > } > > - > static void make_tx_response(struct xenvif_queue *queue, > - struct xen_netif_tx_request *txp, > + const struct xen_netif_tx_request *txp, > unsigned int extra_count, > - s8 st) > + s8 status) > { > - RING_IDX i = queue->tx.rsp_prod_pvt; > - struct xen_netif_tx_response *resp; > - > - resp = RING_GET_RESPONSE(&queue->tx, i); > - resp->id = txp->id; > - resp->status = st; > - > - while (extra_count-- != 0) > - RING_GET_RESPONSE(&queue->tx, ++i)->status = XEN_NETIF_RSP_NULL; > + unsigned long flags; > > - queue->tx.rsp_prod_pvt = ++i; > -} > + spin_lock_irqsave(&queue->response_lock, flags); > > -static void push_tx_responses(struct xenvif_queue *queue) > -{ > - int notify; > + _make_tx_response(queue, txp, extra_count, status); > + push_tx_responses(queue); > > - RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(&queue->tx, notify); > - if (notify) > - notify_remote_via_irq(queue->tx_irq); > + spin_unlock_irqrestore(&queue->response_lock, flags); > } > > static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx) From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:15:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:15:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674528.1049520 (Exim 4.92) (envelope-from ) id 1rVZjD-0007VX-MP; Thu, 01 Feb 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 674528.1049520; Thu, 01 Feb 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 1rVZjD-0007VQ-Io; Thu, 01 Feb 2024 16:15:51 +0000 Received: by outflank-mailman (input) for mailman id 674528; Thu, 01 Feb 2024 16:15: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 1rVZjC-0007VK-71 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:15:50 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 2942478f-c11d-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 17:15:49 +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; Thu, 1 Feb 2024 17:15:47 +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; Thu, 1 Feb 2024 17:15:47 +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: 2942478f-c11d-11ee-8a43-1f161083a0e0 From: John Ernberg To: Peng Fan , Julien Grall , "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/hE0ez5bDzxxsAgAA1KwCAANPCAIAAypGA Date: Thu, 1 Feb 2024 16:15:47 +0000 Message-ID: <71234f8d-c6e1-4294-88ca-22682fd222f5@actia.se> References: <20240131114952.305805-1-john.ernberg@actia.se> <20240131114952.305805-2-john.ernberg@actia.se> <494d4961-ad8a-4d1d-aaa6-d1bfb9d6a137@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: 37303A2958D72955667264 Content-Type: text/plain; charset="utf-8" Content-ID: <43B2996CBED84A4DA2BBEE67688887BE@actia.se> Content-Transfer-Encoding: base64 MIME-Version: 1.0 SGkgUGVuZywNCg0KT24gMi8xLzI0IDA1OjEwLCBQZW5nIEZhbiB3cm90ZToNCj4+IENjOiBKb25h cyBCbGl4dCA8am9uYXMuYmxpeHRAYWN0aWEuc2U+OyB4ZW4tZGV2ZWxAbGlzdHMueGVucHJvamVj dC5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8yXSB4ZW4vYXJtOiBBZGQgaW14OHF7bSx4 fSBwbGF0Zm9ybSBnbHVlDQo+Pg0KPj4gSGkgSnVsaWVuLA0KPj4NCj4+IE9uIDEvMzEvMjQgMTM6 MjIsIEp1bGllbiBHcmFsbCB3cm90ZToNCj4+PiBIaSwNCj4+Pg0KPj4+IE9uIDMxLzAxLzIwMjQg MTE6NTAsIEpvaG4gRXJuYmVyZyB3cm90ZToNCj4+Pj4gV2hlbiB1c2luZyBMaW51eCBmb3IgZG9t MCB0aGVyZSBhcmUgYSBidW5jaCBvZiBkcml2ZXJzIHRoYXQgbmVlZCB0bw0KPj4+PiBkbyBTTUMg U0lQIGNhbGxzIGludG8gdGhlIFBTQ0kgcHJvdmlkZXIgdG8gZW5hYmxlIGNlcnRhaW4gaGFyZHdh cmUNCj4+Pj4gYml0cyBsaWtlIHRoZSB3YXRjaGRvZy4NCj4+Pg0KPj4+IERvIHlvdSBrbm93IHdo aWNoIHByb3RvY29sIHRoaXMgaXMgdW5kZXIgdGhlIGhvb2QuIElzIHRoaXMgU0NNST8NCj4+DQo+ PiBJIHRoaW5rIEkgY29uZnVzZWQgbXlzZWxmIGhlcmUgd2hlbiBJIHdyb3RlIHRoZSBjb21taXQg bG9nLg0KPj4NCj4+IFRoZSBFTDMgY29kZSBpbiBvdXIgY2FzZSBpcyBBVEYsIGFuZCBpdCBkb2Vz IG5vdCBhcHBlYXIgdG8gYmUgU0NNSSwgbm9yIFBTQ0kuDQo+PiBUaGUgcmVnaXN0ZXIgdXNhZ2Ug b2YgdGhlc2UgU01DIFNJUCBjYWxscyBhcmUgYXMgZm9sbG93czoNCj4+IGEwIC0gc2VydmljZQ0K Pj4gYTEgLSBmdW5jdGlvbg0KPj4gYTItYTcgLSBhcmdzDQo+Pg0KPj4gSW4gQVRGIHRoZSBoYW5k bGVyIGlzIGRlY2xhcmVkIGFzIGEgcnVudGltZSBzZXJ2aWNlLg0KPj4NCj4+IFdvdWxkIHRoZSBh cHByb3ByaWF0ZSBjb21tbWl0IG1lc3NhZ2UgaGVyZSBiZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxp bmVzDQo+PiBvZiBiZWxvdz8NCj4+ICIiIg0KPj4gV2hlbiB1c2luZyBMaW51eCBmb3IgZG9tMCB0 aGVyZSBhcmUgYSBidW5jaCBvZiBkcml2ZXJzIHRoYXQgbmVlZCB0byBkbw0KPj4gU01DDQo+PiBT SVAgY2FsbHMgaW50byB0aGUgZmlybXdhcmUgdG8gZW5hYmxlIGNlcnRhaW4gaGFyZHdhcmUgYml0 cyBsaWtlIHRoZSB3YXRjaGRvZy4NCj4+ICIiIg0KPj4+DQo+Pj4+DQo+Pj4+IFByb3ZpZGUgYSBi YXNpYyBwbGF0Zm9ybSBnbHVlIHRoYXQgaW1wbGVtZW50cyB0aGUgbmVlZGVkIFNNQyBmb3J3YXJk aW5nLg0KPj4+Pg0KPj4+PiBTaWduZWQtb2ZmLWJ5OiBKb2huIEVybmJlcmcgPGpvaG4uZXJuYmVy Z0BhY3RpYS5zZT4NCj4+Pj4gLS0tDQo+Pj4+IE5PVEU6IFRoaXMgaXMgYmFzZWQgb24gY29kZSBm b3VuZCBpbiBOWFAgWGVuIHRyZWUgbG9jYXRlZCBoZXJlOg0KPj4+PiBodHRwczovL2V1cjAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXQNCj4+ Pj4gaHViLmNvbSUyRm54cC1pbXglMkZpbXgteGVuJTJGYmxvYiUyRmxmLQ0KPj4gNS4xMC55XzQu MTMlMkZ4ZW4lMkZhcmNoJTJGYXINCj4+Pj4NCj4+IG0lMkZwbGF0Zm9ybXMlMkZpbXg4cW0uYyZk YXRhPTA1JTdDMDIlN0NwZW5nLmZhbiU0MG54cC5jb20lN0MNCj4+IDU3M2I1OTlhDQo+Pj4+DQo+ PiA0YjQxNDNjZWNhMWQwOGRjMjI3MWU1YmUlN0M2ODZlYTFkM2JjMmI0YzZmYTkyY2Q5OWM1YzMw MTYzNSU3Qw0KPj4gMCU3QzAlNw0KPj4+Pg0KPj4gQzYzODQyMzExOTc3NzYwMTU0OCU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakENCj4+IHdNREFpTENKUUkNCj4+Pj4NCj4+ IGpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMCU3QyU3QyU3QyZz ZGF0YT1aTw0KPj4gMFRYakw2DQo+Pj4+IGcwVzdUSVpvOHg4bFROQlhFWlclMkJETmNMUG5kV2xF ZjVEMkElM0QmcmVzZXJ2ZWQ9MA0KPj4+DQo+Pj4gQW55dGhpbmcgYWZ0ZXIgLS0tIHdpbGwgYmUg cmVtb3ZlZCB3aGlsZSBhcHBsaWVkIHRvIHRoZSB0aHJlZS4gSSB0aGluaw0KPj4+IHRoaXMgTk9U RSBzaG91bGQgYmUgd3JpdHRlbiBkb3duIGluIHRoZSBjb21taXQgbWVzc2FnZS4NCj4+DQo+PiBB Y2suDQo+Pj4NCj4+PiBZb3UgYWxzbyBwb3NzaWJseSB3YW50IGEgc2lnbmVkLW9mZi1ieSBmcm9t IFBlbmcgYXMgdGhpcyBpcyBoaXMgY29kZS4NCj4+DQo+PiBAUGVuZzogTWF5IEkgYWRkIGEgc2ln bi1vZmYgZnJvbSB5b3U/DQo+IA0KPiBZZWFoLiBZb3UgY291bGQgYWRkIG15IHNpZ24gb2ZmLg0K DQpHcmVhdCwgdGhhbmtzIQ0KPiANCj4+Pg0KPj4+Pg0KPj4+PiAgwqAgeGVuL2FyY2gvYXJtL3Bs YXRmb3Jtcy9NYWtlZmlsZSB8wqAgMSArDQo+Pj4+ICDCoCB4ZW4vYXJjaC9hcm0vcGxhdGZvcm1z L2lteDhxbS5jIHwgNjUNCj4+Pj4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+ Pj4+ICDCoCAyIGZpbGVzIGNoYW5nZWQsIDY2IGluc2VydGlvbnMoKykNCj4+Pj4gIMKgIGNyZWF0 ZSBtb2RlIDEwMDY0NCB4ZW4vYXJjaC9hcm0vcGxhdGZvcm1zL2lteDhxbS5jDQo+Pj4+DQo+Pj4+ IGRpZmYgLS1naXQgYS94ZW4vYXJjaC9hcm0vcGxhdGZvcm1zL01ha2VmaWxlDQo+Pj4+IGIveGVu L2FyY2gvYXJtL3BsYXRmb3Jtcy9NYWtlZmlsZSBpbmRleCA4NjMyZjQxMTVmLi5iZWM2ZTU1ZDFm DQo+PiAxMDA2NDQNCj4+Pj4gLS0tIGEveGVuL2FyY2gvYXJtL3BsYXRmb3Jtcy9NYWtlZmlsZQ0K Pj4+PiArKysgYi94ZW4vYXJjaC9hcm0vcGxhdGZvcm1zL01ha2VmaWxlDQo+Pj4+IEBAIC05LDUg KzksNiBAQCBvYmotJChDT05GSUdfQUxMX1BMQVQpwqDCoCArPSBzdW54aS5vDQo+Pj4+ICDCoCBv YmotJChDT05GSUdfQUxMNjRfUExBVCkgKz0gdGh1bmRlcngubw0KPj4+PiAgwqAgb2JqLSQoQ09O RklHX0FMTDY0X1BMQVQpICs9IHhnZW5lLXN0b3JtLm8NCj4+Pj4gIMKgIG9iai0kKENPTkZJR19B TEw2NF9QTEFUKSArPSBicmNtLXJhc3BiZXJyeS1waS5vDQo+Pj4+ICtvYmotJChDT05GSUdfQUxM NjRfUExBVCkgKz0gaW14OHFtLm8NCj4+Pj4gIMKgIG9iai0kKENPTkZJR19NUFNPQ19QTEFURk9S TSnCoCArPSB4aWxpbngtenlucW1wLm8NCj4+Pj4gIMKgIG9iai0kKENPTkZJR19NUFNPQ19QTEFU Rk9STSnCoCArPSB4aWxpbngtenlucW1wLWVlbWkubyBkaWZmIC0tZ2l0DQo+Pj4+IGEveGVuL2Fy Y2gvYXJtL3BsYXRmb3Jtcy9pbXg4cW0uYw0KPj4gYi94ZW4vYXJjaC9hcm0vcGxhdGZvcm1zL2lt eDhxbS5jDQo+Pj4+IG5ldyBmaWxlIG1vZGUgMTAwNjQ0IGluZGV4IDAwMDAwMDAwMDAuLmE5Y2Q5 YzM2MTUNCj4+Pj4gLS0tIC9kZXYvbnVsbA0KPj4+PiArKysgYi94ZW4vYXJjaC9hcm0vcGxhdGZv cm1zL2lteDhxbS5jDQo+Pj4+IEBAIC0wLDAgKzEsNjUgQEANCj4+Pj4gKy8qIFNQRFgtTGljZW5z ZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9yLWxhdGVyICovDQo+Pj4+ICsvKg0KPj4+PiArICogeGVu L2FyY2gvYXJtL3BsYXRmb3Jtcy9pbXg4cW0uYw0KPj4+PiArICoNCj4+Pj4gKyAqIGkuTVggOFFN IHNldHVwDQo+Pj4+ICsgKg0KPj4+PiArICogQ29weXJpZ2h0IChjKSAyMDE2IEZyZWVzY2FsZSBJ bmMuDQo+Pj4+ICsgKiBDb3B5cmlnaHQgMjAxOC0yMDE5IE5YUA0KPj4+PiArICoNCj4+Pj4gKyAq DQo+Pj4+ICsgKiBQZW5nIEZhbiA8cGVuZy5mYW5AbnhwLmNvbT4NCj4+Pj4gKyAqLw0KPj4+PiAr DQo+Pj4+ICsjaW5jbHVkZSA8YXNtL3BsYXRmb3JtLmg+DQo+Pj4+ICsjaW5jbHVkZSA8YXNtL3Nt Y2NjLmg+DQo+Pj4+ICsNCj4+Pj4gK3N0YXRpYyBjb25zdCBjaGFyICogY29uc3QgaW14OHFtX2R0 X2NvbXBhdFtdIF9faW5pdGNvbnN0ID0gew0KPj4+PiArwqDCoMKgICJmc2wsaW14OHFtIiwNCj4+ Pj4gK8KgwqDCoCAiZnNsLGlteDhxeHAiLA0KPj4+PiArwqDCoMKgIE5VTEwNCj4+Pj4gK307DQo+ Pj4+ICsNCj4+Pj4gK3N0YXRpYyBib29sIGlteDhxbV9zbWMoc3RydWN0IGNwdV91c2VyX3JlZ3Mg KnJlZ3MpIHsNCj4+Pg0KPj4+IFlvdXIgaW1wbGVtZW50YXRpb24gYmVsb3cgd2lsbCBub3Qgb25s eSBmb3J3YXJkIFNNQyBmb3IgZG9tMCBidXQgYWxzbw0KPj4+IGZvciBhbnkgbm9uLXRydXN0ZWQg ZG9tYWlucy4gSGF2ZSB5b3UgaW52ZXN0aWdhdGVkIHRoYXQgYWxsIHRoZSBTSVANCj4+PiBjYWxs cyBhcmUgc2FmZSB0byBiZSBjYWxsZWQgYnkgYW55b25lPw0KPj4NCj4+IFdlIHVzZSBwdXJlIHZp cnR1YWxpemVkIGRvbVVzLCBzbyB3ZSBkbyBub3QgZXhwZWN0IGFueSBjYWxscyB0byB0aGlzIFNN Qw0KPj4gaW50ZXJmYWNlIGZyb20gdGhlIGd1ZXN0LiBJJ2xsIGxpbWl0IGl0IHRvIGRvbTAuDQo+ IA0KPiBXb3VsZCB5b3UgbWluZCB0byBzaGFyZSB3aGF0IGZlYXR1cmVzIGFyZSBzdXBwb3J0ZWQg aW4geW91ciBEb21VPw0KPiANCj4gUHVyZSB2aXJ0dWFsaXplZCwgeW91IHVzaW5nIHhlbiBwdiBv ciB2aXJ0aW8/DQoNCk5vdCBhdCBhbGwuIFdlJ3JlIGZvcndhcmRpbmcgYmxvY2sgYW5kIG5ldHdv cmtpbmcgKGFuZCBhZGRpdGlvbmFsbHkgDQp1c2JpcCBvdmVyIG5ldHdvcmtpbmcgZm9yIFVTQiBz aGFyaW5nKSwgdmlhIHRoZSBYZW4gUFYgZHJpdmVycy4NCj4gDQo+IFRoYW5rcywNCj4gUGVuZy4N Cj4gDQoNClRoYW5rcyEgLy8gSm9obiBFcm5iZXJn From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:17:09 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:17:09 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674531.1049530 (Exim 4.92) (envelope-from ) id 1rVZkS-0008Bi-VA; Thu, 01 Feb 2024 16:17:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674531.1049530; Thu, 01 Feb 2024 16: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 1rVZkS-0008Bb-S9; Thu, 01 Feb 2024 16:17:08 +0000 Received: by outflank-mailman (input) for mailman id 674531; Thu, 01 Feb 2024 16: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 1rVZkR-0008BT-8f for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:17:07 +0000 Received: from mail.actia.se (mail.actia.se [212.181.117.226]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 579aba30-c11d-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 17:17:06 +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; Thu, 1 Feb 2024 17:17:06 +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; Thu, 1 Feb 2024 17:17:06 +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: 579aba30-c11d-11ee-8a43-1f161083a0e0 From: John Ernberg To: Julien Grall , Stefano Stabellini , Bertrand Marquis , "Michal Orzel" , Volodymyr Babchuk , Peng Fan 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/hE0ez5bDzxxsAgAA1KwCAAVx5AIAAQjeA Date: Thu, 1 Feb 2024 16:17:05 +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> In-Reply-To: <167f0c7a-e037-446c-82f8-2584e35a7af1@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: 37303A2958D72955667264 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 T24gMi8xLzI0IDEzOjIwLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+IA0KPiANCj4gT24gMzEvMDEv MjAyNCAxNTozMiwgSm9obiBFcm5iZXJnIHdyb3RlOg0KPj4gSGkgSnVsaWVuLA0KPiANCj4gSGkg Sm9obiwNCj4gDQo+PiBPbiAxLzMxLzI0IDEzOjIyLCBKdWxpZW4gR3JhbGwgd3JvdGU6DQo+Pj4g SGksDQo+Pj4NCj4+PiBPbiAzMS8wMS8yMDI0IDExOjUwLCBKb2huIEVybmJlcmcgd3JvdGU6DQo+ Pj4+IFdoZW4gdXNpbmcgTGludXggZm9yIGRvbTAgdGhlcmUgYXJlIGEgYnVuY2ggb2YgZHJpdmVy cyB0aGF0IG5lZWQgdG8gZG8NCj4+Pj4gU01DDQo+Pj4+IFNJUCBjYWxscyBpbnRvIHRoZSBQU0NJ IHByb3ZpZGVyIHRvIGVuYWJsZSBjZXJ0YWluIGhhcmR3YXJlIGJpdHMgDQo+Pj4+IGxpa2UgdGhl DQo+Pj4+IHdhdGNoZG9nLg0KPj4+DQo+Pj4gRG8geW91IGtub3cgd2hpY2ggcHJvdG9jb2wgdGhp cyBpcyB1bmRlciB0aGUgaG9vZC4gSXMgdGhpcyBTQ01JPw0KPj4NCj4+IEkgdGhpbmsgSSBjb25m dXNlZCBteXNlbGYgaGVyZSB3aGVuIEkgd3JvdGUgdGhlIGNvbW1pdCBsb2cuDQo+Pg0KPj4gVGhl IEVMMyBjb2RlIGluIG91ciBjYXNlIGlzIEFURiwgYW5kIGl0IGRvZXMgbm90IGFwcGVhciB0byBi ZSBTQ01JLCBub3INCj4+IFBTQ0kuIFRoZSByZWdpc3RlciB1c2FnZSBvZiB0aGVzZSBTTUMgU0lQ IGNhbGxzIGFyZSBhcyBmb2xsb3dzOg0KPj4gYTAgLSBzZXJ2aWNlDQo+PiBhMSAtIGZ1bmN0aW9u DQo+PiBhMi1hNyAtIGFyZ3MNCj4+DQo+PiBJbiBBVEYgdGhlIGhhbmRsZXIgaXMgZGVjbGFyZWQg YXMgYSBydW50aW1lIHNlcnZpY2UuDQo+Pg0KPj4gV291bGQgdGhlIGFwcHJvcHJpYXRlIGNvbW1t aXQgbWVzc2FnZSBoZXJlIGJlIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMNCj4+IG9mIGJlbG93 Pw0KPj4gIiIiDQo+PiBXaGVuIHVzaW5nIExpbnV4IGZvciBkb20wIHRoZXJlIGFyZSBhIGJ1bmNo IG9mIGRyaXZlcnMgdGhhdCBuZWVkIHRvIA0KPj4gZG/CoMKgIFNNQw0KPj4gU0lQIGNhbGxzIGlu dG8gdGhlIGZpcm13YXJlIHRvIGVuYWJsZSBjZXJ0YWluIGhhcmR3YXJlIGJpdHMgbGlrZSB0aGUN Cj4+IHdhdGNoZG9nLg0KPj4gIiIiDQo+IA0KPiBJdCByZWFkcyBiZXR0ZXIgdGhhbmtzLg0KPiAN Cj4gWy4uLl0NCj4gDQo+Pj4gQnV0IGV2ZW4gaWYgd2UgcmVzdHJpY3QgdG8gZG9tMCwgaGF2ZSB5 b3UgY2hlY2tlZCB0aGF0IG5vbmUgb2YgdGhlIFNNQ3MNCj4+PiB1c2UgYnVmZmVycz8NCj4+IEkg aGF2ZW4ndCBmb3VuZCBhbnkgc3VjaCBpbnN0YW5jZXMgaW4gdGhlIExpbnV4IGtlcm5lbCB3aGVy ZSBhIGJ1ZmZlciBpcw0KPj4gdXNlZC4gQWRkaW5nIGEgY2FsbCBmaWx0ZXJpbmcgbGlrZSBzdWdn ZXN0ZWQgYmVsb3cgYWRkaXRpb25zIG9mIHN1Y2gNCj4+IGZ1bmN0aW9ucyBjYW4gYmUgZGlzY292 ZXJlZCBhbmQgYWRhcHRlZCBmb3IgaWYgdGhleSB3b3VsZCBzaG93IHVwIGxhdGVyLg0KPj4+DQo+ Pj4gUmF0aGVyIHRoYW4gcHJvdmlkaW5nIGEgYmxhbmtldCBmb3J3YXJkLCB0byBtZSBpdCBzb3Vu ZHMgbW9yZSBsaWtlIHlvdQ0KPj4+IHdhbnQgdG8gcHJvdmlkZSBhbiBhbGxvd2xpc3Qgb2YgdGhl IFNNQ3MuIFRoaXMgaXMgbW9yZSBmdXR1cmVwcm9vZiBhbmQNCj4+PiBhdm9pZCB0aGUgcmlzayB0 byBleHBvc2UgdW5zYWZlIFNNQ3MgdG8gYW55IGRvbWFpbi4NCj4+Pg0KPj4+IEZvciBhbiBleGFt cGxlLCB5b3UgY2FuIGhhdmUgYSBsb29rIGF0IHRoZSBFRU1JIG1lZGlhdG9yIGZvciBYaWxpbngu DQo+Pg0KPj4gQWNrLiBEbyB5b3UgcHJlZmVyIHRvIHNlZSBvbmx5IG9uIFNNQ0NDIHNlcnZpY2Ug bGV2ZWwgb3IgYWxzbyBvbg0KPj4gZnVuY3Rpb24gbGV2ZWw/IChhMSByZWdpc3RlciwgcGVyIGRl c2NyaXB0aW9uIGVhcmxpZXIpDQo+IA0KPiBJIGFtIG5vdCBzdXJlLiBJdCB3aWxsIGRlcGVuZCBv biB3aGV0aGVyIGl0IGlzIGNvcnJlY3QgdG8gZXhwb3NlICphbGwqIA0KPiB0aGUgZnVuY3Rpb25z IHdpdGhpbiBhIHNlcnZpY2UgbGV2ZWwgYW5kIHRoZXkgaGF2ZSB0aGUgc2FtZSBmb3JtYXQuDQo+ IA0KPiBJZiB5b3UgY2FuJ3QgZ3VhcmFudGVlIHRoYXQsIHRoZW4geW91IHdpbGwgbW9zdCBsaWtl bHkgbmVlZCB0byBhbGxvd2xpc3QgDQo+IGF0IHRoZSBmdW5jdGlvbiBsZXZlbC4NCj4gDQo+IEFs c28sIGRvIHlvdSBoYXZlIGEgc3BlYyBpbiBoYW5kIHRoYXQgd291bGQgaGVscCB0byB1bmRlcnN0 YW5kIHdoaWNoIA0KPiBzZXJ2aWNlL2Z1bmN0aW9uIGlzIGltcGxlbWVudGVkIHZpYSB0aG9zZSBT TUNzPw0KDQpJIGRvbid0IGhhdmUgdGhlIHNwZWMgdW5mb3J0dW5hdGVseSwgYnV0IEkgd2lsbCBh ZGQgYSBmaWx0ZXIgb24gYm90aCANCnNlcnZpY2UgYW5kIGZ1bmN0aW9uIGZvciBWMiBhbmQgd2Un bGwgdGFrZSBpdCBmcm9tIHRoZXJlLg0KPiANCj4gQ2hlZXJzLA0KPiANCg0KVGhhbmtzISAvLyBK b2huIEVybmJlcmc= From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:20:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:20:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674535.1049541 (Exim 4.92) (envelope-from ) id 1rVZnq-0002Us-F8; Thu, 01 Feb 2024 16:20:38 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674535.1049541; Thu, 01 Feb 2024 16:20: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 1rVZnq-0002Ul-B7; Thu, 01 Feb 2024 16:20:38 +0000 Received: by outflank-mailman (input) for mailman id 674535; Thu, 01 Feb 2024 16:20: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 1rVZno-0002UK-Bz for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:20:36 +0000 Received: from gandalf.ozlabs.org (mail.ozlabs.org [2404:9400:2221:ea00::3]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d0e4465b-c11d-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 17:20:33 +0100 (CET) Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by gandalf.ozlabs.org (Postfix) with ESMTP id 4TQkf30k39z4wcW; Fri, 2 Feb 2024 03:20:27 +1100 (AEDT) Received: from authenticated.ozlabs.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 mail.ozlabs.org (Postfix) with ESMTPSA id 4TQkdZ2ZRRz4wcN; Fri, 2 Feb 2024 03:20:02 +1100 (AEDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d0e4465b-c11d-11ee-98f5-efadbce2ee36 Message-ID: Date: Thu, 1 Feb 2024 17:19:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 22/47] hw/arm/aspeed: use qemu_configure_nic_device() Content-Language: en-US To: David Woodhouse , qemu-devel@nongnu.org Cc: Richard Henderson , Beniamino Galvani , Peter Maydell , Strahinja Jankovic , Niek Linnenbank , Andrew Jeffery , Joel Stanley , Igor Mitsyanko , Jean-Christophe Dubois , Andrey Smirnov , =?UTF-8?Q?Philippe_Mathieu-Daud=C3=A9?= , Rob Herring , Subbaraya Sundeep , Jan Kiszka , Tyrone Ting , Hao Wu , Radoslaw Biernacki , Leif Lindholm , Marcin Juszkiewicz , "Edgar E. Iglesias" , Alistair Francis , Helge Deller , Paolo Bonzini , Eduardo Habkost , "Michael S. Tsirkin" , Marcel Apfelbaum , Song Gao , Thomas Huth , Laurent Vivier , Huacai Chen , Jiaxun Yang , =?UTF-8?Q?Herv=C3=A9_Poussineau?= , Aleksandar Rikalo , Aurelien Jarno , Jason Wang , Jia Liu , Stafford Horne , Mark Cave-Ayland , Nicholas Piggin , Daniel Henrique Barboza , David Gibson , Harsh Prateek Bora , Bin Meng , Palmer Dabbelt , Weiwei Li , Liu Zhiwei , Halil Pasic , Christian Borntraeger , Eric Farman , David Hildenbrand , Ilya Leoshkevich , Yoshinori Sato , Magnus Damm , Artyom Tarasenko , Stefano Stabellini , Anthony Perard , Paul Durrant , Max Filippov , qemu-arm@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, xen-devel@lists.xenproject.org, David Woodhouse References: <20240126173228.394202-1-dwmw2@infradead.org> <20240126173228.394202-23-dwmw2@infradead.org> From: =?UTF-8?Q?C=C3=A9dric_Le_Goater?= In-Reply-To: <20240126173228.394202-23-dwmw2@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/26/24 18:24, David Woodhouse wrote: > From: David Woodhouse > > Signed-off-by: David Woodhouse > Acked-by: Cédric Le Goater and Reviewed-by: Cédric Le Goater Thanks, C. > --- > hw/arm/aspeed.c | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c > index cc59176563..bed5e4f40b 100644 > --- a/hw/arm/aspeed.c > +++ b/hw/arm/aspeed.c > @@ -356,7 +356,6 @@ static void aspeed_machine_init(MachineState *machine) > AspeedMachineClass *amc = ASPEED_MACHINE_GET_CLASS(machine); > AspeedSoCClass *sc; > int i; > - NICInfo *nd = &nd_table[0]; > > bmc->soc = ASPEED_SOC(object_new(amc->soc_name)); > object_property_add_child(OBJECT(machine), "soc", OBJECT(bmc->soc)); > @@ -371,10 +370,10 @@ static void aspeed_machine_init(MachineState *machine) > &error_fatal); > > for (i = 0; i < sc->macs_num; i++) { > - if ((amc->macs_mask & (1 << i)) && nd->used) { > - qemu_check_nic_model(nd, TYPE_FTGMAC100); > - qdev_set_nic_properties(DEVICE(&bmc->soc->ftgmac100[i]), nd); > - nd++; > + if ((amc->macs_mask & (1 << i)) && > + !qemu_configure_nic_device(DEVICE(&bmc->soc->ftgmac100[i]), > + true, NULL)) { > + break; /* No configs left; stop asking */ > } > } > From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:30:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:30:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674542.1049550 (Exim 4.92) (envelope-from ) id 1rVZxH-0005mb-H0; Thu, 01 Feb 2024 16:30:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674542.1049550; Thu, 01 Feb 2024 16: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 1rVZxH-0005mU-Bd; Thu, 01 Feb 2024 16:30:23 +0000 Received: by outflank-mailman (input) for mailman id 674542; Thu, 01 Feb 2024 16:30:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVZxG-0005mK-4s; Thu, 01 Feb 2024 16: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 1rVZxG-0004oj-17; Thu, 01 Feb 2024 16: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 1rVZxF-0002oH-GD; Thu, 01 Feb 2024 16:30:21 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rVZxF-00081n-Fe; Thu, 01 Feb 2024 16:30: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=9YpjMy9I01TpieSQ6jpM/g+5JXXXsb5ycykMpNe1yVg=; b=qfOlRYyqIB+n4yGMqklx1lcUgd 94MqpPANMC/+mxsBqJuDWkG//M9f2/xSRB6+j14DWgStexaFAjPP/ijuDi3SbfmWjEPf//0uE1Erq EXcCcDL+8dbG3QR3b/W1AbqnjcUo4w8mr+mXvnItFuPvaUhXSTMy6mv9nWRSgTA8PcgM=; 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] 184545: tolerable FAIL - PUSHED X-Osstest-Failures: linux-linus:test-arm64-arm64-xl-xsm:xen-boot:fail:heisenbug 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-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-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-credit1:migrate-support-check:fail:nonblocking linux-linus:test-arm64-arm64-xl-credit1: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-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-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-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-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-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-xl-credit1:migrate-support-check:fail:nonblocking linux-linus:test-armhf-armhf-xl-credit1:saverestore-support-check:fail:nonblocking X-Osstest-Versions-This: linux=6764c317b6bb91bd806ef79adf6d9c0e428b191e X-Osstest-Versions-That: linux=861c0981648f5b64c86fd028ee622096eb7af05a From: osstest service owner Date: Thu, 01 Feb 2024 16:30:21 +0000 flight 184545 linux-linus real [real] flight 184550 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/184545/ http://logs.test-lab.xenproject.org/osstest/logs/184550/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-xsm 8 xen-boot fail pass in 184550-retest Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 15 migrate-support-check fail in 184550 never pass test-arm64-arm64-xl-xsm 16 saverestore-support-check fail in 184550 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stop fail like 184525 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail like 184525 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stop fail like 184525 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 184525 test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail like 184525 test-armhf-armhf-libvirt 16 saverestore-support-check fail like 184525 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail like 184525 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 184525 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-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-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 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-qcow2 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-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-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 version targeted for testing: linux 6764c317b6bb91bd806ef79adf6d9c0e428b191e baseline version: linux 861c0981648f5b64c86fd028ee622096eb7af05a Last test of basis 184525 2024-01-30 04:10:43 Z 2 days Failing since 184534 2024-01-30 23:45:05 Z 1 days 2 attempts Testing same since 184545 2024-01-31 22:37:40 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Alexander Gordeev Anders Roxell Arthur Grillo Chunhai Guo Colin Ian King Dan Carpenter David Gow Gao Xiang Jingbo Xu Joe Lawrence Kees Cook Li RongQing Linus Torvalds Marco Pagani Marcos Paulo de Souza Mark Brown Martin K. Petersen Mathieu Desnoyers Michael Kelley Michael S. Tsirkin Ming Lei Miroslav Benes Rae Moar Richard Fitzgerald Sathya Prakash Veerichetty Shuah Khan Su Hui Tyrel Datwyler 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 fail 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 861c0981648f..6764c317b6bb 6764c317b6bb91bd806ef79adf6d9c0e428b191e -> tested/linux-linus From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:40:38 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:40:38 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674549.1049560 (Exim 4.92) (envelope-from ) id 1rVa76-0008KE-CI; Thu, 01 Feb 2024 16:40:32 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674549.1049560; Thu, 01 Feb 2024 16:40: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 1rVa76-0008K7-9E; Thu, 01 Feb 2024 16:40:32 +0000 Received: by outflank-mailman (input) for mailman id 674549; Thu, 01 Feb 2024 16:40: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 1rVa74-0008Jx-Nm for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:40:30 +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 9b2579f0-c120-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 17:40:29 +0100 (CET) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C963C61F9D; Thu, 1 Feb 2024 16:40:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id ED7CAC43399; Thu, 1 Feb 2024 16:40:26 +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 D639DD8C97B; Thu, 1 Feb 2024 16:40:26 +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: 9b2579f0-c120-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706805627; bh=tUGHjQXZc4kPtsp3kBrK8stZgKY4d0Sjj2hXbau2+tw=; h=Subject:From:Date:References:In-Reply-To:To:Cc:From; b=VfJZ0QH3JSTZZIgOoOIZVp+7MvzJdERSMVdJrd7Nz3wf6BV+idXCMDx4tOcaTmvat fxmPMtckf+EgnLTFPSQgP+8PFLohotnQa8Y73hUITcqIffQ818riTNTFzmzMBDfb+x lqRcmaJib3eQlM6Bs/nkFhdsotdm+9+pU5XwzS5R1XNhZejmtoY2KQX1zi5IBVNhjs frvKdkUdX+klk0Nz3k+cWF4y52HNIuv9tO2vavaZpWzr9Fi04wQMA4jDiQ8OSgFZwz fxk1x53xSh9Yg8N0jUCPDUPEC3/Gx+Hxv1sJYy5QKNuCs+V3fQxgU4dnlaTpml7b4V 4VibnUIC34LDg== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [PATCH net] xen-netback: properly sync TX responses From: patchwork-bot+netdevbpf@kernel.org Message-Id: <170680562687.32005.2375881723958020276.git-patchwork-notify@kernel.org> Date: Thu, 01 Feb 2024 16:40:26 +0000 References: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> In-Reply-To: <980c6c3d-e10e-4459-8565-e8fbde122f00@suse.com> To: Jan Beulich Cc: netdev@vger.kernel.org, wl@xen.org, paul@xen.org, xen-devel@lists.xenproject.org Hello: This patch was applied to netdev/net.git (main) by Jakub Kicinski : On Mon, 29 Jan 2024 14:03:08 +0100 you wrote: > Invoking the make_tx_response() / push_tx_responses() pair with no lock > held would be acceptable only if all such invocations happened from the > same context (NAPI instance or dealloc thread). Since this isn't the > case, and since the interface "spec" also doesn't demand that multicast > operations may only be performed with no in-flight transmits, > MCAST_{ADD,DEL} processing also needs to acquire the response lock > around the invocations. > > [...] Here is the summary with links: - [net] xen-netback: properly sync TX responses https://git.kernel.org/netdev/net/c/7b55984c96ff 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 Thu Feb 01 16:51:56 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:51:56 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674553.1049569 (Exim 4.92) (envelope-from ) id 1rVaHx-0002gt-BP; Thu, 01 Feb 2024 16:51:45 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674553.1049569; Thu, 01 Feb 2024 16:51: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 1rVaHx-0002gm-8a; Thu, 01 Feb 2024 16:51:45 +0000 Received: by outflank-mailman (input) for mailman id 674553; Thu, 01 Feb 2024 16:51: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 1rVaHw-0002fT-DY for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:51:44 +0000 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [2607:f8b0:4864:20::435]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 2c4ffda2-c122-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 17:51:42 +0100 (CET) Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-6da6b0eb2d4so886546b3a.1 for ; Thu, 01 Feb 2024 08:51: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: 2c4ffda2-c122-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706806300; x=1707411100; 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=pHgO2N+l6o7ljfKXbnAdMBmgfTYXAOxMzwYRNwJOjdc=; b=Y+1uv5kVKuqautBdz9r0hgNodRR5rLugkj7q2Wpiio4EbLwxvLHVmTNp/Q4ZJ/zWkY y58Cz3mjc+fX9tpeQXM+7RjhCl2q+fk+Jjm2p6ibDDOHWcx76v3ymtQmcr8Loc8Tr9eP K81l9EcsSfDoz1kllEsCTkuc60dKO5eggVJWOFzr7d1ZEJ4WkQEvW2x7I3DzrUU1ASOt 6lhNenZbjcOLVrbcVbbsY5AQ+Ol53FLe0GIoo2XCajukKInM+RcI1dpcFgxPZBE95NQz MMeQwulMo3JYy1VsqwuM5Y8gCeBdqaJ8whlIninJX7Z0VxLyPYDfPgrIkonPWxjsKfwl cSIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806300; x=1707411100; 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=pHgO2N+l6o7ljfKXbnAdMBmgfTYXAOxMzwYRNwJOjdc=; b=qd0q5UY4GUH2gMBH/MIDfRKX4J5aDKNh1o7J4x8xnIyi4GI7vVl4dyqVCdr4LFXkZm nukRwE3eXoELLus6u6Y0ueZzcY9u1xFXFxiOy8iMlTcFrSQfuSuw+kv/+jQX/7k+w01G +fnVV9DmBURTeyBl5+HEnKmC1DAwwPtSI5Cik8cUbbWtm4zYaORaJqw78wI0hluWB6wz JRVLITT/IfMMzIQOvbwYya3S6VepdaRQX9GDpbJErpn0ZMzdPxEKyVa/IdPDQGp70xGQ /Snx2UMw+L8q+f00T7Y8SdYWcfHyXvXZIB7bJgktJNhlfnh+cl1HsHKRXVsWBFZwP1zn aAIQ== X-Gm-Message-State: AOJu0YxqfgztfK+O1x+C2oTRtzlm9Pk8+i27DlY9LklzjaCoQjJGogbf U4g9sjOLGQl5d5yaNkiEfw8mrhOK5CgAimqu5dGJBek1/cBJubLLwYfAlQQLShLmNY6HtowaQfq biNTJiXkuLAhFaL03JHO+Fp56zF8= X-Google-Smtp-Source: AGHT+IHaHkuZaTIehF3ZXnPaTmy4AEtFZTyIYcHEjMM+enOgb7CO+yg+2maj9afol4UoDChrKOKvieU9a+/6Yw/rdbU= X-Received: by 2002:a05:6a00:181c:b0:6dd:c870:3f82 with SMTP id y28-20020a056a00181c00b006ddc8703f82mr7032844pfa.4.1706806300407; Thu, 01 Feb 2024 08:51:40 -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: Thu, 1 Feb 2024 17:51:28 +0100 Message-ID: Subject: Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD To: Mario Limonciello Cc: Jan Beulich , xen-devel@lists.xenproject.org, Juergen Gross , =?UTF-8?Q?Marek_Marczykowski=2DG=C3=B3recki?= Content-Type: multipart/alternative; boundary="0000000000003c7d2d061054cf25" --0000000000003c7d2d061054cf25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le jeu. 1 f=C3=A9vr. 2024 =C3=A0 13:30, S=C3=A9bastien Chaumat a =C3=A9crit : > I spotted the following warning for IRQ7 (along with IRQ6 and 10) > > [ 0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type > function for IRQ 7 (IR-IO-APIC) > > This comes from kernel/irq/manage.c > > > int __irq_set_trigger(struct irq_desc *desc, unsigned long flags) > { > struct irq_chip *chip =3D desc->irq_data.chip; > int ret, unmask =3D 0; > > if (!chip || !chip->irq_set_type) { > /* > * IRQF_TRIGGER_* but the PIC does not support multiple > * flow-types? > */ > pr_debug("No set_type function for IRQ %d (%s)\n", > irq_desc_get_irq(desc), > chip ? (chip->name ? : "unknown") : "unknown"); > return 0; > } > Could this have a role in the IRQ misconfiguration by xen ? > Things are getting even weirder : xen 4.18.1-pre (vanilla, no patching of pci_xen_initial_domain()), kernel 6.8.0-rc2) : checking /sys/kernel/irq/7 : actions: pinctrl_amd chip_name: xen-pirq hwirq: name: ioapic-edge per_cpu_count: 0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0 type: edge wakeup: disabled now checking xen with xl debug-key i (XEN) IRQ: 7 vec:51 IO-APIC-level status=3D030 aff:{13}/{13} in-flight=3D0 d0: 7(---) (XEN) IRQ 7 Vec 81: (XEN) Apic 0x00, Pin 7: vec=3D51 delivery=3DFixed dest=3DP status=3D= 1 polarity=3D1 irr=3D1 trig=3DL mask=3D0 dest_id:0000510d So even after dom0 is set up, the kernel considers IRQ7 is of type edge while xen has it registered as IO-APIC-level. --0000000000003c7d2d061054cf25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable








Le=C2=A0jeu. 1 f=C3= =A9vr. 2024 =C3=A0=C2=A013:30, S=C3=A9bastien Chaumat <euidzero@gmail.com> a =C3=A9c= rit=C2=A0:
I spotted the following warning for IRQ7 (along with IRQ6 = and 10)

[ =C2=A0 =C2=A00.686073] fedora k= ernel: __irq_set_trigger: genirq: No set_type function for IRQ 7 (IR-IO-API= C)

This comes from kernel/irq/manage.c
=


int __irq_set_trigger(struct irq_desc *desc, = unsigned long flags)
{
struct irq_chip *chip =3D desc->irq_data.ch= ip;
int ret, unmask =3D 0;

if (!chip || !chip->irq_set_type) {=
/*
* IRQF_TRIGGER_* but the PIC does not support multiple
* flow-= types?
*/
pr_debug("No set_type function for IRQ %d (%s)\n"= ,
irq_desc_get_irq(desc),
chip ? (chip->name ? : "unknown&quo= t;) : "unknown");
return 0;
}
Could this have a role in= the IRQ misconfiguration by xen ?

=C2=A0Things are getting even weirder :

xen 4.18.1-pre (vanilla, no patching of pci_xen_initi= al_domain()), kernel 6.8.0-rc2) :

checking /sys/kern= el/irq/7 :

actions: pinctrl_amd
chip_name: xen-= pirq
hwirq:
name: ioapic-edge
per_cpu_count: 0,0,0,0,0,0,1,0,0,0,= 0,0,0,0,0,0
type: edge
wakeup: disabled

now = checking=C2=A0 xen with xl debug-key i

(XEN) =C2= =A0 =C2=A0IRQ: =C2=A0 7 vec:51 IO-APIC-level =C2=A0 status=3D030 aff:{13}/{= 13} in-flight=3D0 d0: =C2=A07(---)
(XEN) =C2=A0 =C2=A0 IRQ = =C2=A07 Vec 81:
(XEN) =C2=A0 =C2=A0 =C2=A0 Apic 0x00, Pin =C2=A07: vec= =3D51 delivery=3DFixed dest=3DP status=3D1 polarity=3D1 irr=3D1 trig=3DL ma= sk=3D0 dest_id:0000510d

So even after dom0 is set = up, the kernel considers=C2=A0 IRQ7 is of type edge while xen has it regist= ered as IO-APIC-level.


--0000000000003c7d2d061054cf25-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:55:28 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:55:28 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674557.1049580 (Exim 4.92) (envelope-from ) id 1rVaLT-0003RI-T3; Thu, 01 Feb 2024 16:55:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674557.1049580; Thu, 01 Feb 2024 16: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 1rVaLT-0003RB-QN; Thu, 01 Feb 2024 16:55:23 +0000 Received: by outflank-mailman (input) for mailman id 674557; Thu, 01 Feb 2024 16: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 1rVaLS-0003R5-G8 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:55:22 +0000 Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [2a00:1450:4864:20::234]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id aefe8879-c122-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 17:55:20 +0100 (CET) Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2cf1288097aso15575301fa.0 for ; Thu, 01 Feb 2024 08:55: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: aefe8879-c122-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706806520; x=1707411320; 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=RBRoiFhzBwl5VFAP4C+wSNH9W94y9ZIzJo2QLJgsqTM=; b=acovdA5UYl4Y7QJUzxQiTAjAWKSE0+ZCpH8ElH6jluz6jwtPOwvKD1Cmeufg48qqHF 1G1Coz7v58k/sVHmqPLOgZmvRi0PTKGDlI+Arzwx+RJ1ao+wvllsMmiMcBizI36yrb2o 0kCWG5UbFrrODDID7h0ulWWJHCIcsYrgXsOB8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806520; x=1707411320; 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=RBRoiFhzBwl5VFAP4C+wSNH9W94y9ZIzJo2QLJgsqTM=; b=XmtKB6yrP6chDq1twnJ7niwk2pjhMojicbD5bQk/SVAKX27fmEk6/NLVAD8wxcjFNc SbiHIRb9fY7/lpVtq43DJI4PrQreq4om/Ms5KCxHfHkIcskdxHYT6bvQ6hlKd8myOABF DF3wQFtt6cyRqFqi+uFD6n8JK/6B3EVfi+sJvnlYA4N+9mllnNGUbD/4Xa4lENX1iUUZ af7nvVdDyHBofJ11LpgdOkUe4nK+/e7fxrPAi87+efoaw88HmiQV58IQblHLZy5yVmr2 e6suKcvGSg/Baj0NK1cmbHdmQ6ysrnNKncO3pkoRcF2f0hXIWdVS7fEWiAWA/Q695A+E r4kg== X-Gm-Message-State: AOJu0YyCbm0XJRcZQLKs76MVsc3mMlvJqQpYY/b9noQDTzGg2KIyy0g0 FCGk6QZU/zvV+X5hizorGMPfsuTOESa+Z3mfdjQBgmo2CLwK38/1aj4Byj6X4/LJP0Q/N9f/7WX ohSPEQJbzUWvLqB9efZwgDs690H5aYKgSuxOSkw== X-Google-Smtp-Source: AGHT+IFMO8fChOZ+UHjzvt1AawyangJW+kQdJkUS6kcWOuEeYgsZ8hD7DskmrNqhrWCEIJFKNgf1UYcIsGa+df8Rytk= X-Received: by 2002:a2e:b0f7:0:b0:2d0:7dab:d45e with SMTP id h23-20020a2eb0f7000000b002d07dabd45emr959137ljl.9.1706806519868; Thu, 01 Feb 2024 08:55:19 -0800 (PST) MIME-Version: 1.0 References: <1be8f6f1-f977-4743-bd26-362ada960dc6@vates.tech> In-Reply-To: <1be8f6f1-f977-4743-bd26-362ada960dc6@vates.tech> From: George Dunlap Date: Thu, 1 Feb 2024 16:55:08 +0000 Message-ID: Subject: Re: Next steps for Rust guest agent To: Yann Dirson Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu , Lunfan Zhang , Xihuan Yang , dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 11, 2024 at 12:27=E2=80=AFPM Yann Dirson wrote: > > - what should be the criteria to advertise it as official Xenproject > > guest agent ? > > What do people think here? As we discussed at the community call, I think that we should basically set a date at which we consider this the official Xen Project guest agent. Anyone who wants to have input can give it before then. Then once you guys think it's ready, we can start to "market" it to the distros. Shall we say 29 February, 8 weeks from now? -George From xen-devel-bounces@lists.xenproject.org Thu Feb 01 16:57:15 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 16:57:15 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674560.1049590 (Exim 4.92) (envelope-from ) id 1rVaNC-0003yW-7o; Thu, 01 Feb 2024 16:57:10 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674560.1049590; Thu, 01 Feb 2024 16: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 1rVaNC-0003yP-4m; Thu, 01 Feb 2024 16:57:10 +0000 Received: by outflank-mailman (input) for mailman id 674560; Thu, 01 Feb 2024 16:57:08 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVaNA-0003yH-Qi for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 16:57:08 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVaN8-0005Gl-Px; Thu, 01 Feb 2024 16:57:06 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rVaN8-0003uN-HP; Thu, 01 Feb 2024 16:57: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=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=qgZJCfdLDu8JYR0LsPiclE/eQBuhsWgYjnA8lKA8aOc=; b=Zg5EhqUmnKmEqg2nTWgRTCi6UC wTGtaWHah0fwFn+1OvePB8NU//0FkGY37MzQ+VOaDMe8Mc+eZfwssbG6LaqALzzpPesRvc44gKYgV T/S2Je17Ry9N4/e3LpE19WyVFrQmAR1EqD0++8rRVao7eQLHH1tWKwl5+9KjFDyBYMeg=; Message-ID: <9e01b86e-e3d2-4eec-93ed-e8828375bb30@xen.org> Date: Thu, 1 Feb 2024 16:57:04 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Next steps for Rust guest agent Content-Language: en-GB To: George Dunlap , Yann Dirson Cc: xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich , Stefano Stabellini , Wei Liu , Lunfan Zhang , Xihuan Yang , dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com References: <1be8f6f1-f977-4743-bd26-362ada960dc6@vates.tech> From: Julien Grall In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi George, On 01/02/2024 16:55, George Dunlap wrote: > On Thu, Jan 11, 2024 at 12:27 PM Yann Dirson wrote: >>> - what should be the criteria to advertise it as official Xenproject >>> guest agent ? >> >> What do people think here? > > As we discussed at the community call, I think that we should > basically set a date at which we consider this the official Xen > Project guest agent. Anyone who wants to have input can give it > before then. Then once you guys think it's ready, we can start to > "market" it to the distros. +1 > > Shall we say 29 February, 8 weeks from now? This is 4 weeks away. I am fine with that, but checking this is the date you intended to set. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:11 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:11 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674564.1049600 (Exim 4.92) (envelope-from ) id 1rVaS0-0006nL-Q2; Thu, 01 Feb 2024 17:02:08 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674564.1049600; Thu, 01 Feb 2024 17:02: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 1rVaS0-0006nE-Mw; Thu, 01 Feb 2024 17:02:08 +0000 Received: by outflank-mailman (input) for mailman id 674564; Thu, 01 Feb 2024 17:02: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 1rVaRz-0006n8-B6 for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:07 +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 a0fa446c-c123-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:02:06 +0100 (CET) Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5112bd13a4fso1135889e87.0 for ; Thu, 01 Feb 2024 09:02: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: a0fa446c-c123-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1706806926; x=1707411726; 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=FHF+v7x8/QeBquQOP44XZ2/os7VovEFQTEi/GM6OTH4=; b=Wmy1rCxqHgFoAQYJEYhbAE5m3yMqIxu5GNWr6s/0uX70Tyf7VqOKSCTZU60RuaSy4G 2nuLkTLzQGCfXKTFfh6uGnrhABSXgaf4j5Q5uF4tMt3TRhWv7tAclMqw58dQVpN94x3a AkGhJUPXbqaZW1qIyAIFqlHyVHh4j+oAQhGPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806926; x=1707411726; 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=FHF+v7x8/QeBquQOP44XZ2/os7VovEFQTEi/GM6OTH4=; b=sM5Xu/bTexV5tcnbrMV5UBu1ihy7Hc+NjEojaNDHRKveOIgwJJQImC0259MRo+0CA6 z+61zKamjyO9oe5e/8u7/5wzKqzw5J+uPK/30lbkRQ7m15AfMlBpd1kijgrnRLNJYPoK 3ubzvicoXYdgy83xZSWR65oUPWa0RqmfYuveytwSibvdwiea5T2w0r47NQzV0Liy0lPw dOGM5ztVzK2HxMlhUVsnyvCC2zhAkT65fCQQEN78fnKLyG8a6feKPpMmr5+6hah/T/UL P82NB1Rq616y/rRBueAFS7pURrhPYU2JaD2Ve+/jXk/3ky5YFxGHh/As/BBChkJaFwRI 1sSQ== X-Gm-Message-State: AOJu0YyzX0MFIWAsFL1rmenEwIxBefTbIsdJ3dygw+VIlasV3Jrpm+qa L21ZtL4TaIP3W6WpbVhj5GTzyTev/F3RvWsC3xDVcMCBN+YueKb1eBX0Dl8WoMjgpy9eMLkJ3Ve EMDmEtu5/naGUuR4+kfn2jSGlkltxN2IfdGiMLw== X-Google-Smtp-Source: AGHT+IGxxLinwhS09HN0SxRzAxnFm0ip6c3RZ2uSi9UQHrxxNFviyXmgu7rTp7e9YNMAxeEUr8I2tvpYdgYqHeZk/LI= X-Received: by 2002:a05:6512:286:b0:510:22c4:fbaf with SMTP id j6-20020a056512028600b0051022c4fbafmr1076144lfp.13.1706806925753; Thu, 01 Feb 2024 09:02:05 -0800 (PST) MIME-Version: 1.0 References: <1be8f6f1-f977-4743-bd26-362ada960dc6@vates.tech> <9e01b86e-e3d2-4eec-93ed-e8828375bb30@xen.org> In-Reply-To: <9e01b86e-e3d2-4eec-93ed-e8828375bb30@xen.org> From: George Dunlap Date: Thu, 1 Feb 2024 17:01:54 +0000 Message-ID: Subject: Re: Next steps for Rust guest agent To: Julien Grall Cc: Yann Dirson , xen-devel@lists.xenproject.org, Andrew Cooper , Jan Beulich , Stefano Stabellini , Wei Liu , Lunfan Zhang , Xihuan Yang , dpsmith@apertussolutions.com, marmarek@invisiblethingslab.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 1, 2024 at 4:57=E2=80=AFPM Julien Grall wrote: > > Hi George, > > On 01/02/2024 16:55, George Dunlap wrote: > > On Thu, Jan 11, 2024 at 12:27=E2=80=AFPM Yann Dirson wrote: > >>> - what should be the criteria to advertise it as official Xenproject > >>> guest agent ? > >> > >> What do people think here? > > > > As we discussed at the community call, I think that we should > > basically set a date at which we consider this the official Xen > > Project guest agent. Anyone who wants to have input can give it > > before then. Then once you guys think it's ready, we can start to > > "market" it to the distros. > > +1 > > > > > Shall we say 29 February, 8 weeks from now? > > This is 4 weeks away. I am fine with that, but checking this is the date > you intended to set. ... I have no idea how that 8 got there... yes, 4 weeks is what I meant to writ= e. -George From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674565.1049609 (Exim 4.92) (envelope-from ) id 1rVaS8-00073L-0E; Thu, 01 Feb 2024 17:02:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674565.1049609; Thu, 01 Feb 2024 17: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 1rVaS7-00073E-TP; Thu, 01 Feb 2024 17:02:15 +0000 Received: by outflank-mailman (input) for mailman id 674565; Thu, 01 Feb 2024 17: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 1rVaS5-0006n8-UR for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:13 +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 a5210a0e-c123-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:02:13 +0100 (CET) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-558f523c072so1708116a12.2 for ; Thu, 01 Feb 2024 09:02:13 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id o11-20020a056402444b00b0055d3d1653b3sm6617362edb.31.2024.02.01.09.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09:02: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: a5210a0e-c123-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706806932; x=1707411732; 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=Wz8hnYroCYqHv9y7dmqbQbjNnQAdCfNne5v071bTWRE=; b=L7qau/I88cftDBnfnPoIVFPpEfVzHfPyGzFntfcQNEdf70FfYlbSUEz8zBckuJVCbk gItcX53QfiKGUrpA4qRjiUPddySOzmFtvFypek/Ct8X4xuVdxpy9Ol0PGbKXy3sSTIr2 dUPXb4WIhm8pegJCw9Wt0qeYl7idr1Te+jj74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806932; x=1707411732; 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=Wz8hnYroCYqHv9y7dmqbQbjNnQAdCfNne5v071bTWRE=; b=UTQY1fBtdqB8jiScLoLLt/A1E02nxx5a13pkf+pOhH0YmdV6VDnh/etZR2oID395S3 FnSPesFlDGQ6sR+fzd4u6puM28wNjGNBNmUQephyVaOCKRJK9ojdFPoSE3KybXEt2wUD fiXC89AvVXq8jbw9p/2kirDJ1RE7BrJzwvv9skGmXvhOYMo6R1E+uhakWgDwh1V3vBpO V0a3yYvltdN2S6ccGprz9/SnWwAj1N51bzdZUOfLz5rL1GiCwHKoWjXGNQT0+lUcGvkr BkOoZ4yrILvW2unRhsrbrlM16jVSdzDPizcbgNuDQYwTt0iabYDoFe3/VpfHQ1/9ZIAn zPBg== X-Gm-Message-State: AOJu0YyuVM0fuvr60th+E4PwoyZT8ZJLDDmb0kraTPs9bapF6lmNKIWj K6aJcyPvvK3UHLXcjvlfdxmvTDG9esw4elv69roTyUjwHrw3mK1cIzJ9f3R7buWlFoeBZ6+bAKI j X-Google-Smtp-Source: AGHT+IFr5vIuvATmEU3Lizj2zwmteX8aji47igUJODCkyit0aMkH+H6HN7Dwi3X0Bl5wJUh8C0YAoA== X-Received: by 2002:aa7:c354:0:b0:55f:6960:4935 with SMTP id j20-20020aa7c354000000b0055f69604935mr4160521edr.25.1706806932627; Thu, 01 Feb 2024 09:02:12 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCV9RMEgIwUIj0rcfz0UfGOs/2ICwuB5BCl4gBnTB3w4gK7fy4/e3a0ECQLXSpr0yZXm51FqwEuqN1S4M19xYSTtfARfnLKTBgmnwpnzJMKWBniBKwyJxR1CA9tK0MwZgy8+UkKPB/75QU/ycccohpvFlqUk3kFgjFjMfHMyoUZIXnVdyrP7BXWe8hbtLGkeVcuNQ9/eFSJiD9+aZps= From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , oxjo@proton.me, Wei Liu , Paul Durrant , Kevin Tian Subject: [PATCH 0/4] iommu/x86: fixes/improvements for unity range checks Date: Thu, 1 Feb 2024 18:01:55 +0100 Message-ID: <20240201170159.66330-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello, Patch 1 is a bugfix for AMD-Vi IVMD range type checks. Further patches unify the IVMD/RMRR checks into a common function, and the last patch tightens up the condition to panic when attempting to boot on a system that has RMRR or IVMD regions over memory that Xen uses as RAM. Thanks, Roger. Roger Pau Monne (4): amd-vi: fix IVMD memory type checks iommu/x86: introduce a generic IVMD/RMRR range validity helper iommu/vt-d: switch to common RMRR checker iommu/x86: make unity range checking more strict xen/arch/x86/include/asm/iommu.h | 3 ++ xen/drivers/passthrough/amd/iommu_acpi.c | 33 ++--------------- xen/drivers/passthrough/vtd/dmar.c | 14 ++------ xen/drivers/passthrough/x86/iommu.c | 46 ++++++++++++++++++++++++ 4 files changed, 55 insertions(+), 41 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:18 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:18 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674566.1049614 (Exim 4.92) (envelope-from ) id 1rVaS8-00076i-8K; Thu, 01 Feb 2024 17:02:16 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674566.1049614; Thu, 01 Feb 2024 17: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 1rVaS8-00075f-3y; Thu, 01 Feb 2024 17:02:16 +0000 Received: by outflank-mailman (input) for mailman id 674566; Thu, 01 Feb 2024 17:02: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 1rVaS7-0006n8-1s for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:15 +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 a5a8341b-c123-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:02:14 +0100 (CET) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-55c2cf644f3so1537824a12.1 for ; Thu, 01 Feb 2024 09:02:14 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id h29-20020a0564020e9d00b0055cfb3f948fsm7002015eda.76.2024.02.01.09.02.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09:02: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: a5a8341b-c123-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706806933; x=1707411733; 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=gGkbw6NMRmq84Zwm3toJg408+YkNymy6A8aNzx/GF0M=; b=WOgFGmp4wAlVZe5KSBYm4fBKBfSBdlk357RV5UIFLOIru8f2k4iKop1hFKpyyOsv+m 9eTCf2nQTsmJtMbWPob3emXPsseqQ6Tyo163yfi79jv0fUyS3wXsaiHyRLTMkOknuix6 rwiZdvEC0MCUlF73TCII3pjH6o4OkGBu8gGoM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806933; x=1707411733; 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=gGkbw6NMRmq84Zwm3toJg408+YkNymy6A8aNzx/GF0M=; b=cswMIbBaMh+zeqbZqHUXNVTRszQ443nA03LvhFWvvvdrPz+7u5FhMn9ElEF5O7XAhY NsqabZco3oqGMFhoIa6AZIRCFOiEIFGaw9R5ZlF363FYOotD1V+AowWPrYBABhgOx1cX Ynmv/s6cBqr6xeiaHQfYodbzV0oo3+lC1WmqruMjGhtNFlbA61YRdpnWcs6P8sPuzhGJ NCrKUcLu0pNAO8SFQj1U7rveKMimGICvyLGhEIiammNb05MdPw5zdq/oFNzGdlkDMNpY gVGZtX52SSktFTnMZDZoQG7kU7/+Pgn9iePeSiWp4ARmdFF5/Dh2ejC4hxr3cFDb/jFH J9ng== X-Gm-Message-State: AOJu0YwBWlLuUPfCz8KVb01b9ZfVFgLOn4NJ18wED09R4Zsrs+DS+hRs 3mAh+fFmYgXwT7bhvjaC3E+RnGzK2hdMnX7sSgZfUDXKVu57hSgiT2vzHx1C9hLTnb/r2mNRuiE M X-Google-Smtp-Source: AGHT+IGIMAX9xEfzp7fazur889a6R83N+pLnidiTerN578sP+ra2lpf0shXr+EPsnqASXyDum22iXA== X-Received: by 2002:aa7:d5c6:0:b0:55e:dcdf:50b0 with SMTP id d6-20020aa7d5c6000000b0055edcdf50b0mr3590001eds.15.1706806933771; Thu, 01 Feb 2024 09:02:13 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXa7/kBApDrW+9oLGL5JuXgqFjsL7REMMsbCNkqEymxKzmK6rPiWX8gjFOgJ9L8ciruSynzi2zHvP4pAUa5PQrrhSdSTpsLNI5FKIRo7qkN7zxWhxL5+OreNCiZeAN0U91XWHZnH50iqfzKV8M= From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , oxjo@proton.me Subject: [PATCH 1/4] amd-vi: fix IVMD memory type checks Date: Thu, 1 Feb 2024 18:01:56 +0100 Message-ID: <20240201170159.66330-2-roger.pau@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201170159.66330-1-roger.pau@citrix.com> References: <20240201170159.66330-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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é --- Cc: oxjo@proton.me --- xen/drivers/passthrough/amd/iommu_acpi.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index 2e3b83014beb..ca70f4f3ae2c 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -426,9 +426,14 @@ static int __init parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block) return -EIO; } - /* Types which won't be handed out are considered good enough. */ - if ( !(type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | - RAM_TYPE_UNUSABLE)) ) + /* + * Types which aren't RAM are considered good enough. + * Note that a page being partially RESERVED, ACPI or UNUSABLE will + * force Xen into assuming the whole page as having that type in + * practice. + */ + if ( type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | + RAM_TYPE_UNUSABLE) ) continue; AMD_IOMMU_ERROR("IVMD: page at %lx can't be converted\n", addr); -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674567.1049630 (Exim 4.92) (envelope-from ) id 1rVaSB-0007ZD-G6; Thu, 01 Feb 2024 17:02:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674567.1049630; Thu, 01 Feb 2024 17:02: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 1rVaSB-0007Z0-Cy; Thu, 01 Feb 2024 17:02:19 +0000 Received: by outflank-mailman (input) for mailman id 674567; Thu, 01 Feb 2024 17:02: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 1rVaS9-0007Wp-Vh for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:17 +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 a67f37fb-c123-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 18:02:15 +0100 (CET) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a354408e6bfso393531766b.1 for ; Thu, 01 Feb 2024 09:02:15 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id x13-20020aa7dacd000000b0055eb8830906sm5799854eds.85.2024.02.01.09.02.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09:02: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: a67f37fb-c123-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706806935; x=1707411735; 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=LaBUruy8bPZuvsCRWTLi8TtvG3+zI8gmjxbPMfpVXBQ=; b=lQiuQocOtK++8BUqK7RASUFT0dAorXBb8lITr9CLEtfmLuXp2/rbXS91qk7twI26SL JIAcGZ05qTqkOMnc96G44qVKFmU6AKFHyje8haxM62B/2DavS9hQVSWRR5UMUiWyUeaU YTf2agBBCDfRsbqh3Z8x7R6BWq1q86pl4nG10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806935; x=1707411735; 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=LaBUruy8bPZuvsCRWTLi8TtvG3+zI8gmjxbPMfpVXBQ=; b=ZeKhbMKzxR5HrtUofWqxSMDR4ChAgQs4BI4K61PcZeQO1Lk2YEyi7oLn393Xi3WwGp TmRL4voIf0gJeoPqoYTxSJeaQhn8N6nkdUXKJDGvYDrtosYYmALkFpm3ZjOCAEhKIVHf rOmiIBeY0r38yHQia+JLApTVtp0yV2ELJAAzfIkJCv3gM0hck3JsCBqemLhZ+CXJN5Vi q9VJzUije0PIfZqGlqSe7lf1fG46QMgfyPYkGDpxVcbJqNhTde8hUlNBTaliog1IY6LH hKvEwVpudXlvXgKk4xkVgkISWVJ+vzCYB6m5CY9iMINYxAqCQiJ7YKagzc67cgJxQ2pJ jn/Q== X-Gm-Message-State: AOJu0YwCteBCGziwDdqJLCCbZQ/ql3230lBfKZiQ8UZCgG1VxeqNOAdQ L+/82K9Xch1H83pI86K+UhIAtX+NpJ7B8HYCMvRNkVtbfGDbHXipUNMQjkfIsGzrBh3ofOIClUf Z X-Google-Smtp-Source: AGHT+IGXtQwRJDikIm3QRBpY+NsFJJ2VzaJ8sihA2KkXMbRjVgXNsY2axsutk7Ypvh3WHZBEw62lBw== X-Received: by 2002:a17:907:20ee:b0:a36:83b6:385a with SMTP id rh14-20020a17090720ee00b00a3683b6385amr4052264ejb.7.1706806934981; Thu, 01 Feb 2024 09:02:14 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXz9y6qNecsuzFbhqWvYu586TWh1h6wyME4CUQvvl+rXnQoYcXO6n+vN0EpxXhLKl8Wiu3E8XwBAwUKxc2D8TZVTyBcQfdIoGy5xyisZNJMxu6cseqarQdNLbEAC101yEK4quN+35e9TF0/CLdY3xHpZRi1M43P From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Wei Liu , Paul Durrant Subject: [PATCH 2/4] iommu/x86: introduce a generic IVMD/RMRR range validity helper Date: Thu, 1 Feb 2024 18:01:57 +0100 Message-ID: <20240201170159.66330-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201170159.66330-1-roger.pau@citrix.com> References: <20240201170159.66330-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit IVMD and RMRR ranges are functionally equivalent, and as so could use the same validity checker. Move the IVMD to x86 common IOMMU code and adjust the function to take a pair of [start, end) mfn parameters. So far only the AMD-Vi side is adjusted to use the newly introduced helper, the VT-d side will be adjusted in a further change. No functional change intended. Signed-off-by: Roger Pau Monné --- xen/arch/x86/include/asm/iommu.h | 3 ++ xen/drivers/passthrough/amd/iommu_acpi.c | 38 ++------------------ xen/drivers/passthrough/x86/iommu.c | 46 ++++++++++++++++++++++++ 3 files changed, 52 insertions(+), 35 deletions(-) diff --git a/xen/arch/x86/include/asm/iommu.h b/xen/arch/x86/include/asm/iommu.h index 15a848ddc329..5c7e37331aad 100644 --- a/xen/arch/x86/include/asm/iommu.h +++ b/xen/arch/x86/include/asm/iommu.h @@ -135,6 +135,9 @@ struct page_info *__must_check iommu_alloc_pgtable(struct domain_iommu *hd, uint64_t contig_mask); void iommu_queue_free_pgtable(struct domain_iommu *hd, struct page_info *pg); +/* Check [start, end) unity map range for correctness. */ +bool iommu_unity_region_ok(mfn_t start, mfn_t end); + #endif /* !__ARCH_X86_IOMMU_H__ */ /* * Local variables: diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c b/xen/drivers/passthrough/amd/iommu_acpi.c index ca70f4f3ae2c..40468dbbccf3 100644 --- a/xen/drivers/passthrough/amd/iommu_acpi.c +++ b/xen/drivers/passthrough/amd/iommu_acpi.c @@ -405,41 +405,9 @@ static int __init parse_ivmd_block(const struct acpi_ivrs_memory *ivmd_block) return 0; } - if ( !e820_all_mapped(base, limit + PAGE_SIZE, E820_RESERVED) ) - { - paddr_t addr; - - AMD_IOMMU_WARN("IVMD: [%lx,%lx) is not (entirely) in reserved memory\n", - base, limit + PAGE_SIZE); - - for ( addr = base; addr <= limit; addr += PAGE_SIZE ) - { - unsigned int type = page_get_ram_type(maddr_to_mfn(addr)); - - if ( type == RAM_TYPE_UNKNOWN ) - { - if ( e820_add_range(addr, addr + PAGE_SIZE, - E820_RESERVED) ) - continue; - AMD_IOMMU_ERROR("IVMD: page at %lx couldn't be reserved\n", - addr); - return -EIO; - } - - /* - * Types which aren't RAM are considered good enough. - * Note that a page being partially RESERVED, ACPI or UNUSABLE will - * force Xen into assuming the whole page as having that type in - * practice. - */ - if ( type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | - RAM_TYPE_UNUSABLE) ) - continue; - - AMD_IOMMU_ERROR("IVMD: page at %lx can't be converted\n", addr); - return -EIO; - } - } + if ( !iommu_unity_region_ok(maddr_to_mfn(base), + maddr_to_mfn(limit + PAGE_SIZE)) ) + return -EIO; if ( ivmd_block->header.flags & ACPI_IVMD_EXCLUSION_RANGE ) exclusion = true; diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c index c90755ff58fa..63d4cb898218 100644 --- a/xen/drivers/passthrough/x86/iommu.c +++ b/xen/drivers/passthrough/x86/iommu.c @@ -792,6 +792,52 @@ static int __init cf_check adjust_irq_affinities(void) } __initcall(adjust_irq_affinities); +bool __init iommu_unity_region_ok(mfn_t start, mfn_t end) +{ + mfn_t addr; + + if ( e820_all_mapped(mfn_to_maddr(start), mfn_to_maddr(end), + E820_RESERVED) ) + return true; + + printk(XENLOG_WARNING "IOMMU: [%#" PRI_mfn " ,%#" PRI_mfn + ") is not (entirely) in reserved memory\n", + mfn_x(start), mfn_x(end)); + + for ( addr = start; !mfn_eq(addr, end); mfn_add(addr, 1) ) + { + unsigned int type = page_get_ram_type(addr); + + if ( type == RAM_TYPE_UNKNOWN ) + { + if ( e820_add_range(mfn_to_maddr(addr), + mfn_to_maddr(addr) + PAGE_SIZE, E820_RESERVED) ) + continue; + printk(XENLOG_WARNING + "IOMMU: page at %#" PRI_mfn " couldn't be reserved\n", + mfn_x(addr)); + return false; + } + + /* + * Types which aren't RAM are considered good enough. + * Note that a page being partially RESERVED, ACPI or UNUSABLE will + * force Xen into assuming the whole page as having that type in + * practice. + */ + if ( type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | + RAM_TYPE_UNUSABLE) ) + continue; + + printk(XENLOG_WARNING + "IOMMU: page at %#" PRI_mfn " can't be converted\n", + mfn_x(addr)); + return false; + } + + return true; +} + /* * Local variables: * mode: C -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:19 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:19 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674568.1049635 (Exim 4.92) (envelope-from ) id 1rVaSB-0007c3-Rb; Thu, 01 Feb 2024 17:02:19 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674568.1049635; Thu, 01 Feb 2024 17:02: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 1rVaSB-0007bP-N9; Thu, 01 Feb 2024 17:02:19 +0000 Received: by outflank-mailman (input) for mailman id 674568; Thu, 01 Feb 2024 17:02: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 1rVaSA-0007Wp-Lm for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:18 +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 a74d3c51-c123-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 18:02:17 +0100 (CET) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a357cba4a32so159191166b.2 for ; Thu, 01 Feb 2024 09:02:17 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id hw20-20020a170907a0d400b00a2b1a20e662sm7368698ejc.34.2024.02.01.09.02.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09:02: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: a74d3c51-c123-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706806936; x=1707411736; 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=UloEpPKCM7G82luLru9QjRBa08XW6aQ69k/jBsglyGw=; b=rNbPd2z6k1d03ehIATXiBtiO+aDVtXpX4K5tQpGZmtFiq/LY33nsoVcRmKD21l4l8u RVHSWcClSRMdpzVLEl6yRSzyEahGvdjJMgPsEz4JJ0T7vk8igobml+QAm7bA/JVeCLmP UW19WIipZPnMk4+PmfysralqiLq5u9Xgz+YGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806936; x=1707411736; 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=UloEpPKCM7G82luLru9QjRBa08XW6aQ69k/jBsglyGw=; b=JdNWZsxBO+Ii5htEvhm/g9K3ti/lNh1/TeEFyDtlp/c76VXQNsVdvFcHF1682yz9Fy 0ytg4qj5QH2e9W530nE/pgjgswHrsxeFc6lup7r1ByKTFXK1aOfbLQbOJVahm9S+Rdvh 9ZCSbQn0LSrwk2Ys2zvHFFZM2q43S5Aej4bpWuVLQnOabtEABrixhQVKmEk21Ex3KMqz vKw/VwCuoktGVD2erjnMQHnHf6d0Y5HF8s9jpe5t1nVubAa7rHr/g+diz5KTOlYQ472Z U8MUPADt7tS9WUOCob0qsZHrD2o9BnzgePXOehC68OExvNdYZuBgbsCIeMV1g8Y4RPC+ b/dQ== X-Gm-Message-State: AOJu0Yx2UVHkzkWxaD7J+dNFsoc99iu9nfVxYTtKr+L+52B0XM+L29Tt bGdN7btVXhuun3TX/xHGZJzUlr8/N7Fseh3X+2ELZXWNc6aLIVdjUOzYg7kxmzxZUUGeMLQniIm w X-Google-Smtp-Source: AGHT+IE1ioEOtkHXIsPlEbxeCQ5KNW6gZONtNKo7ovJn0q0tGWZV/t+8E8s+EtazaGjUEAvRtXy5GA== X-Received: by 2002:a17:906:3515:b0:a36:2dc:1903 with SMTP id r21-20020a170906351500b00a3602dc1903mr2272370eja.68.1706806936197; Thu, 01 Feb 2024 09:02:16 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCXRcHbpgIR2NyN9m6tWAgLtB7nbJPyYIh6UIkvdWkRs8hEq9Bn5Xp1NNCrN4gxyPsb4MxHHLpBB+H/4soWBdQS6v6r3gQ== From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Kevin Tian Subject: [PATCH 3/4] iommu/vt-d: switch to common RMRR checker Date: Thu, 1 Feb 2024 18:01:58 +0100 Message-ID: <20240201170159.66330-4-roger.pau@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201170159.66330-1-roger.pau@citrix.com> References: <20240201170159.66330-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Use the newly introduced generic unity map checker. Also drop the message recommending the usage of iommu_inclusive_mapping: the ranges would end up being mapped anyway even if some of the checks above failed, regardless of whether iommu_inclusive_mapping is set. Signed-off-by: Roger Pau Monné --- xen/drivers/passthrough/vtd/dmar.c | 14 +++----------- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c index 07772f178fe6..005b42706a34 100644 --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -642,17 +642,9 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header) return -EEXIST; } - /* This check is here simply to detect when RMRR values are - * not properly represented in the system memory map and - * inform the user - */ - if ( !e820_all_mapped(base_addr, end_addr + 1, E820_RESERVED) && - !e820_all_mapped(base_addr, end_addr + 1, E820_NVS) && - !e820_all_mapped(base_addr, end_addr + 1, E820_ACPI) ) - printk(XENLOG_WARNING VTDPREFIX - " RMRR [%"PRIx64",%"PRIx64"] not in reserved memory;" - " need \"iommu_inclusive_mapping=1\"?\n", - base_addr, end_addr); + if ( !iommu_unity_region_ok(maddr_to_mfn(base_addr), + maddr_to_mfn(end_addr + PAGE_SIZE)) ) + return -EIO; rmrru = xzalloc(struct acpi_rmrr_unit); if ( !rmrru ) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:02:20 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:02:20 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674569.1049641 (Exim 4.92) (envelope-from ) id 1rVaSC-0007iL-98; Thu, 01 Feb 2024 17:02:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674569.1049641; Thu, 01 Feb 2024 17:02: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 1rVaSC-0007gf-1Q; Thu, 01 Feb 2024 17:02:20 +0000 Received: by outflank-mailman (input) for mailman id 674569; Thu, 01 Feb 2024 17:02: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 1rVaSA-0006n8-Nk for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:02:18 +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 a7ed1163-c123-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:02:18 +0100 (CET) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a359e6fde44so123351766b.3 for ; Thu, 01 Feb 2024 09:02:18 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id cu10-20020a170906ba8a00b00a36a94ecf9dsm1031214ejd.175.2024.02.01.09.02.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09:02: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: a7ed1163-c123-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706806937; x=1707411737; 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=MrhtNQnEdn9vrYvKxplKdOmWw8AltePzlQHZOnCcYkE=; b=TREy726yqQyCNCvxbN4sQq49dv4v/hR85PC4SXyzmDbx1h2mFnLOECrsNCDdiUhhmA Ld82CPHRMEHkuQ/KXqx5wHuWO34L8VdvELZYW0kE0uU5eC+zvBcj6O7HEv3RUcfyTen0 ygEamOCONVXjYDzw4zJVfMpKvC/jhgpXEzVOg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706806937; x=1707411737; 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=MrhtNQnEdn9vrYvKxplKdOmWw8AltePzlQHZOnCcYkE=; b=NOdHIKklLmsUQEAdrffdW3Np4z0Z5HI7AW1xc5EDJ4Cotu+Nc3BNl7K4xOL8gxmRK2 gZtkq7C8N19sVf5PSJjnb88oHGSczinMOQGIj9IffGuJliVhnx16Jh6ATP5LX0adNyzA d9rmYZDMc+ao+eCpcGIiFO4N6FYeUw4gcCI/iwbochqGOBKQoIBfRbCUlzGHbKkw6hBE rXZVhDxTQhGtSaXgw1VjV1pR+xd6TzT+QuFnBXTJoz7/+NUCN7KkwxfucYk0FhY6asps 7C8gDHVwW9I6nJnOka95DYwDov6w+qo9SSeRp74Oe0lqLhefqlAQ6i4pVaaAK7dWlJxU MQiA== X-Gm-Message-State: AOJu0YxMKqYGTxHH1nPvzYQQxcwu3tFp3CEmaxX4VSrwQ9voInO55Sc+ 7VXj4NBEd9ENXor97/Jz67XFmxKP9BlApqhM88vfIOPZwAoe6RffUfNH6Tw2h46zk1YKwhGqMHz Z X-Google-Smtp-Source: AGHT+IGc7i6430H4QaIi3+LxQD/GqTuUYou2Jbiu1ErGblVAr8z1YC/aUC4MxNi18CobbC4sV1WzTA== X-Received: by 2002:a17:906:5f96:b0:a35:b7e6:1c44 with SMTP id a22-20020a1709065f9600b00a35b7e61c44mr4170204eju.75.1706806937437; Thu, 01 Feb 2024 09:02:17 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWf11yDgkYofRYjl5BKyx2LV56+rtBBpdJEdCgo5EHCP2ZvruGsNYEccw5XEHxjhlu/nPxBONNJtNXsvcabLciBZDfjnbZ8t8I6raIVlOXf From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Paul Durrant Subject: [PATCH 4/4] iommu/x86: make unity range checking more strict Date: Thu, 1 Feb 2024 18:01:59 +0100 Message-ID: <20240201170159.66330-5-roger.pau@citrix.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201170159.66330-1-roger.pau@citrix.com> References: <20240201170159.66330-1-roger.pau@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently when a unity range overlaps with memory being used as RAM by the hypervisor the result would be that the IOMMU gets disabled. However that's not enough, as even with the IOMMU disabled the device will still access the affected RAM areas. Note that IVMD or RMRR ranges being placed over RAM is a firmware bug. Doing so also allows to simplify the code and use a switch over the reported memory type(s). Signed-off-by: Roger Pau Monné --- xen/drivers/passthrough/x86/iommu.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/xen/drivers/passthrough/x86/iommu.c b/xen/drivers/passthrough/x86/iommu.c index 63d4cb898218..9b977f84582f 100644 --- a/xen/drivers/passthrough/x86/iommu.c +++ b/xen/drivers/passthrough/x86/iommu.c @@ -806,10 +806,14 @@ bool __init iommu_unity_region_ok(mfn_t start, mfn_t end) for ( addr = start; !mfn_eq(addr, end); mfn_add(addr, 1) ) { - unsigned int type = page_get_ram_type(addr); - - if ( type == RAM_TYPE_UNKNOWN ) + /* + * Any page that's at least partially of type RESERVED, UNUSABLE or + * ACPI will be considered by Xen of being all of that type, and hence + * the problematic pages are those that are fully holes or RAM. + */ + switch ( page_get_ram_type(addr) ) { + case RAM_TYPE_UNKNOWN: if ( e820_add_range(mfn_to_maddr(addr), mfn_to_maddr(addr) + PAGE_SIZE, E820_RESERVED) ) continue; @@ -817,7 +821,10 @@ bool __init iommu_unity_region_ok(mfn_t start, mfn_t end) "IOMMU: page at %#" PRI_mfn " couldn't be reserved\n", mfn_x(addr)); return false; - } + + case RAM_TYPE_CONVENTIONAL: + panic("IOMMU: page at %#" PRI_mfn " overlaps RAM range\n", + mfn_x(addr)); /* * Types which aren't RAM are considered good enough. @@ -825,14 +832,7 @@ bool __init iommu_unity_region_ok(mfn_t start, mfn_t end) * force Xen into assuming the whole page as having that type in * practice. */ - if ( type & (RAM_TYPE_RESERVED | RAM_TYPE_ACPI | - RAM_TYPE_UNUSABLE) ) - continue; - - printk(XENLOG_WARNING - "IOMMU: page at %#" PRI_mfn " can't be converted\n", - mfn_x(addr)); - return false; + } } return true; -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:10:55 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:10:55 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674587.1049660 (Exim 4.92) (envelope-from ) id 1rVaaQ-0002fR-AJ; Thu, 01 Feb 2024 17:10:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674587.1049660; Thu, 01 Feb 2024 17: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 1rVaaQ-0002fK-7V; Thu, 01 Feb 2024 17:10:50 +0000 Received: by outflank-mailman (input) for mailman id 674587; Thu, 01 Feb 2024 17:10: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 1rVaaO-0002fC-Nk for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:10:48 +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 d7b13bb1-c124-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:10:47 +0100 (CET) Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a3566c0309fso158463466b.1 for ; Thu, 01 Feb 2024 09:10:47 -0800 (PST) Received: from localhost ([213.195.118.74]) by smtp.gmail.com with ESMTPSA id xa14-20020a170907b9ce00b00a34ae71e58dsm7473352ejc.147.2024.02.01.09.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 09: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: d7b13bb1-c124-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1706807447; x=1707412247; 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=510KNn1Q+2goZvYgFG10wKrbP7MgTGvopo6XgmHSduA=; b=c511vmQT8O1jGlO0HNVMWgEU0bMSxc9Q1AYxGALHb5wOUvaggjdSpg/Z+F+CnTmL/0 tS2lfxlHJANGcegZ3PMp0AsweM0tQt+vxOOO01cCK6wQfaILfrV3ZX3IUERkDbV/zH0l YIs/I1CMmgAj9M9EoXBib43Bfd3+zhtinKYVY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706807447; x=1707412247; 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=510KNn1Q+2goZvYgFG10wKrbP7MgTGvopo6XgmHSduA=; b=Q6OQNQKpyFHqKhVVLL1nca+V2txI4zW5pkrmTWqjGRfv66+XkUZhoiS/iKUaPNTsZr a5DVDnBA2/3wEDYI94gB7xFsoRZz9iouNFdIVjxhMyYutZ8XKsrxHjGWLcAITZDYh4SN fa2nbF8aAlpQ3872Taq0UPw4aZz6qYUVQUhzuYaHjPLK5tZs1omlmrY7z2dE8AXWEFi9 LJsx5Qn7BpNujygJeyjFhVMKRuqU2qLhGhHkAy1LOJhbmAe4qrM6PVJ/PHx/1awNvaQy BU77abXQKekXOrgqvIAlik4ZEW068pS/zoyCnJirUFhPQzUHRRU52P/4o6O7oo+Zuv6H hdmg== X-Gm-Message-State: AOJu0Yx4kCy+4VaAcoNJxXBLwpCRjDhIYaQyqCXjoq42QBec+s7218Hc Dyzw+EsV9M7C4uqb7ORPHh5Fwuq8PK9k2KvukJJ5U2prviHr+etMQp8scq5LnqU= X-Google-Smtp-Source: AGHT+IGMB8bk+RwtbqA2kw8RFjlZrVHfrfFT0UtQLSx8nX7wXIHIn6m63pkC0HTAArmKFfW7Xxq61A== X-Received: by 2002:a17:906:491a:b0:a36:34c7:21a5 with SMTP id b26-20020a170906491a00b00a3634c721a5mr3836938ejq.22.1706807447306; Thu, 01 Feb 2024 09:10:47 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCW3rj632b4k6Bly38eru1TfMXrU1Brj/DVB1CG1KkVRxwmfU+NLcJSgsyEWaPQjVgQmnD9E7P+s7lIa61S0YJvXamPbo/Ah8Ik+43p9BIu+4zJ5kZTcWnsxDLKHdQy2tw0QRBFyZhGd2XVcV5og0TTegfh0fOp1Ydj3IIU4/MqxEMaUUs1SiMGV Date: Thu, 1 Feb 2024 18:10:46 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Jan Beulich Cc: Andrew Cooper , "xen-devel@lists.xenproject.org" , Wei Liu , Kevin Tian , Jun Nakajima Subject: Re: [PATCH v4 3/8] VMX: tertiary execution control infrastructure Message-ID: References: <9dd23064-c79e-4a50-9c71-c0e73b189944@suse.com> <56822f9c-6156-4652-9de1-3d599e22c51a@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56822f9c-6156-4652-9de1-3d599e22c51a@suse.com> On Thu, Feb 01, 2024 at 01:09:11PM +0100, Jan Beulich wrote: > On 01.02.2024 12:50, Roger Pau Monné wrote: > > On Thu, Jan 11, 2024 at 10:00:10AM +0100, Jan Beulich wrote: > >> @@ -503,6 +538,9 @@ static int vmx_init_vmcs_config(bool bsp > >> "Secondary Exec Control", > >> vmx_secondary_exec_control, _vmx_secondary_exec_control); > >> mismatch |= cap_check( > >> + "Tertiary Exec Control", > >> + vmx_tertiary_exec_control, _vmx_tertiary_exec_control); > > > > I know it's done to match the surrounding style, but couldn't you move > > the name parameter one line up, and then limit the call to two lines? > > > > (I don't think it will compromise readability). > > You mean like this: > > mismatch |= cap_check("Tertiary Exec Control", > vmx_tertiary_exec_control, _vmx_tertiary_exec_control); > > ? No, I view this as a mix of two possible styles. If the string literal > was moved up, the other legitimate style would only be > > mismatch |= cap_check("Tertiary Exec Control", > vmx_tertiary_exec_control, > _vmx_tertiary_exec_control); > > aiui (again extending over 3 lines). Yet none of this is written down > anywhere. > > But anyway - consistency with surrounding code trumps here, I think. I was hoping it could still fit on 2 lines, but if you need 3 never mind then. > >> @@ -2068,10 +2111,12 @@ void vmcs_dump_vcpu(struct vcpu *v) > >> vmr(HOST_PERF_GLOBAL_CTRL)); > >> > >> printk("*** Control State ***\n"); > >> - printk("PinBased=%08x CPUBased=%08x SecondaryExec=%08x\n", > >> + printk("PinBased=%08x CPUBased=%08x\n", > >> vmr32(PIN_BASED_VM_EXEC_CONTROL), > >> - vmr32(CPU_BASED_VM_EXEC_CONTROL), > >> - vmr32(SECONDARY_VM_EXEC_CONTROL)); > >> + vmr32(CPU_BASED_VM_EXEC_CONTROL)); > >> + printk("SecondaryExec=%08x TertiaryExec=%08lx\n", > > > > For consistency, shouldn't TertiaryExec use 016 instead of 08 (as it's > > a 64bit filed). > > Perhaps, assuming we'll gets bits 32 and populated sooner or later. > However, I view 16-digit literal numbers as hard to read, so I'd be > inclined to insert a separator (e.g. an underscore) between the low > and high halves. Thoughts? Works for me. Thanks, Roger. From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:18:52 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:18:52 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674596.1049670 (Exim 4.92) (envelope-from ) id 1rVai8-00053Q-3X; Thu, 01 Feb 2024 17:18:48 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674596.1049670; Thu, 01 Feb 2024 17:18: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 1rVai7-00053J-Vw; Thu, 01 Feb 2024 17:18:47 +0000 Received: by outflank-mailman (input) for mailman id 674596; Thu, 01 Feb 2024 17:18: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 1rVai5-00053D-PB for xen-devel@lists.xen.org; Thu, 01 Feb 2024 17:18:46 +0000 Received: from casper.infradead.org (casper.infradead.org [2001:8b0:10b:1236::1]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id f31d2171-c125-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 18:18:44 +0100 (CET) Received: from [205.251.233.53] (helo=freeip.amazon.com) by casper.infradead.org with esmtpsa (Exim 4.97.1 #2 (Red Hat Linux)) id 1rVai0-0000000GNFh-45si; Thu, 01 Feb 2024 17:18: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: f31d2171-c125-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=T9Fs+1NiNaEOfFjfaUDtfOiyuIOFtkmdu6ETtmgrLlk=; b=GW90F22632pdDYARggo0apvbI8 AyaoS6wVbNBejq3AP77VoH6ZBGFK4ypoJwnA/AEhgG0hjAWbXYibuM8Deu38EqQSwdmZmy1/VC/hZ qTUXmaHaj4lySPAe4Som1GgGS1krpbUD8ppWN32cjIF2yGs5WQXqNIVDDB9+kUm7ZruQJVBLqWqeV ZW/eTybKGjIknHtl28vT99syJvMXdhUFrmXVVHB4ia4XRtn2aaNJVYvKVlnY6fiA29KMUru3uweoE eKjj8jsARVJrE/0PqKFjosOu0rCGXdDbU3I1p8YPyCfxkHqooCuvkLM58glyLAbieKUdinH2iN83b YeccKfag==; Message-ID: <4b5b1fdadbabd53116d1ab79295b913c27947c4b.camel@infradead.org> Subject: Re: Nullifying Recently Introduced Xen Headers Check From: David Woodhouse To: "John L. Poole" , xen-devel@lists.xen.org Date: Thu, 01 Feb 2024 09:18:40 -0800 In-Reply-To: References: Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-I6Mgn+WqVKlm+Jzmgs0k" User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html --=-I6Mgn+WqVKlm+Jzmgs0k Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Thanks Andy for the explicit cc) On Thu, 2024-02-01 at 00:05 +0000, John L. Poole wrote: >=20 > cause Gentoo's build to error out.=C2=A0 See line 24790: >=20 > =C2=A0=C2=A0=C2=A0 5 | #error In Xen native files, include xen_native.h b= efore other Xen headers >=20 > at > https://salemdata.us/xen/xen_tools_20240128_Sun_174740.script.html. >=20 > What I have done is create a patch for a draft Gentoo ebuild which > nullifies lines 4-6 by wrapping them in a comment: That isn't what the #error told you to do, though. 24788 In file included from ../qemu-xen/hw/xen/xen-operations.c:16: 24789 /var/tmp/portage/app-emulation/xen-tools-4.18.0/work/xen-4.18.0/tool= s/qemu-xen/include/hw/xen/xen_native.h:5:2: error: #error In Xen native fil= es, include xen_native.h before other Xen headers 24790 5 | #error In Xen native files, include xen_native.h before othe= r Xen headers 24791 | ^~~~~ So it's hw/xen/xen-operations.h which is failing. As far as I can tell (visually and empirically because it does actually build elsewhere), it *is* doing what the #error said =E2=80=94 it *is* including xen_native.h be= fore any other Xen headers.=20 The first four non-comment lines of xen-operations.c should look something like this... #include "qemu/osdep.h" #include "qemu/uuid.h" #include "qapi/error.h" #include "hw/xen/xen_native.h" So... did you patch it so it doesn't start like that any more? Or does one of those first three files (perhaps qemu/osdep.h?) end up bringing in the Xen interface headers in a way that I didn't anticipate and which doesn't seem to happen elsewhere? I didn't cite the full gcc command line from line 24787 of your log because it's huge. Can you run a variant of that command to just give me the *preprocessed* output (-E -dD -o xen-operations.i). --=-I6Mgn+WqVKlm+Jzmgs0k Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEkQw ggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUAMIGIMQswCQYDVQQG EwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5IENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYD VQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAyjztlApB/975Rrno1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUf ItMltrMaXqcESJuK8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeW QcpGEGFUUd0kN+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YB rf24k5Ee1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewD ch/8kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4GA1Ud DwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2NybC51c2Vy dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYGCCsGAQUF BwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJT QUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0G CSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjjsb0XMZHztuOCtKF+ xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9 IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7 kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1 eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4 KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL 1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQ OZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qod x/PL+5jR87myx5uYdBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i 5ZgtwCLXgAIe5W8mybM2JzCCBhQwggT8oAMCAQICEQDGvhmWZ0DEAx0oURL6O6l+MA0GCSqGSIb3 DQEBCwUAMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28g UlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTIyMDEwNzAw MDAwMFoXDTI1MDEwNjIzNTk1OVowJDEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALQ3GpC2bomUqk+91wLYBzDMcCj5C9m6 oZaHwvmIdXftOgTbCJXADo6G9T7BBAebw2JV38EINgKpy/ZHh7htyAkWYVoFsFPrwHounto8xTsy SSePMiPlmIdQ10BcVSXMUJ3Juu16GlWOnAMJY2oYfEzmE7uT9YgcBqKCo65pTFmOnR/VVbjJk4K2 xE34GC2nAdUQkPFuyaFisicc6HRMOYXPuF0DuwITEKnjxgNjP+qDrh0db7PAjO1D4d5ftfrsf+kd RR4gKVGSk8Tz2WwvtLAroJM4nXjNPIBJNT4w/FWWc/5qPHJy2U+eITZ5LLE5s45mX2oPFknWqxBo bQZ8a9dsZ3dSPZBvE9ZrmtFLrVrN4eo1jsXgAp1+p7bkfqd3BgBEmfsYWlBXO8rVXfvPgLs32VdV NZxb/CDWPqBsiYv0Hv3HPsz07j5b+/cVoWqyHDKzkaVbxfq/7auNVRmPB3v5SWEsH8xi4Bez2V9U KxfYCnqsjp8RaC2/khxKt0A552Eaxnz/4ly/2C7wkwTQnBmdlFYhAflWKQ03Ufiu8t3iBE3VJbc2 5oMrglj7TRZrmKq3CkbFnX0fyulB+kHimrt6PIWn7kgyl9aelIl6vtbhMA+l0nfrsORMa4kobqQ5 C5rveVgmcIad67EDa+UqEKy/GltUwlSh6xy+TrK1tzDvAgMBAAGjggHMMIIByDAfBgNVHSMEGDAW gBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUzMeDMcimo0oz8o1R1Nver3ZVpSkwDgYD VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2VjdGln by5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20vU2VjdGln b1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoGCCsGAQUFBwEB BH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdvUlNBQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEFBQcwAYYXaHR0cDovL29j c3Auc2VjdGlnby5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5mcmFkZWFkLm9yZzANBgkqhkiG9w0B AQsFAAOCAQEAyW6MUir5dm495teKqAQjDJwuFCi35h4xgnQvQ/fzPXmtR9t54rpmI2TfyvcKgOXp qa7BGXNFfh1JsqexVkIqZP9uWB2J+uVMD+XZEs/KYNNX2PvIlSPrzIB4Z2wyIGQpaPLlYflrrVFK v9CjT2zdqvy2maK7HKOQRt3BiJbVG5lRiwbbygldcALEV9ChWFfgSXvrWDZspnU3Gjw/rMHrGnql Htlyebp3pf3fSS9kzQ1FVtVIDrL6eqhTwJxe+pXSMMqFiN0whpBtXdyDjzBtQTaZJ7zTT/vlehc/ tDuqZwGHm/YJy883Ll+GP3NvOkgaRGWEuYWJJ6hFCkXYjyR9IzCCBhQwggT8oAMCAQICEQDGvhmW Z0DEAx0oURL6O6l+MA0GCSqGSIb3DQEBCwUAMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMB4XDTIyMDEwNzAwMDAwMFoXDTI1MDEwNjIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALQ3 GpC2bomUqk+91wLYBzDMcCj5C9m6oZaHwvmIdXftOgTbCJXADo6G9T7BBAebw2JV38EINgKpy/ZH h7htyAkWYVoFsFPrwHounto8xTsySSePMiPlmIdQ10BcVSXMUJ3Juu16GlWOnAMJY2oYfEzmE7uT 9YgcBqKCo65pTFmOnR/VVbjJk4K2xE34GC2nAdUQkPFuyaFisicc6HRMOYXPuF0DuwITEKnjxgNj P+qDrh0db7PAjO1D4d5ftfrsf+kdRR4gKVGSk8Tz2WwvtLAroJM4nXjNPIBJNT4w/FWWc/5qPHJy 2U+eITZ5LLE5s45mX2oPFknWqxBobQZ8a9dsZ3dSPZBvE9ZrmtFLrVrN4eo1jsXgAp1+p7bkfqd3 BgBEmfsYWlBXO8rVXfvPgLs32VdVNZxb/CDWPqBsiYv0Hv3HPsz07j5b+/cVoWqyHDKzkaVbxfq/ 7auNVRmPB3v5SWEsH8xi4Bez2V9UKxfYCnqsjp8RaC2/khxKt0A552Eaxnz/4ly/2C7wkwTQnBmd lFYhAflWKQ03Ufiu8t3iBE3VJbc25oMrglj7TRZrmKq3CkbFnX0fyulB+kHimrt6PIWn7kgyl9ae lIl6vtbhMA+l0nfrsORMa4kobqQ5C5rveVgmcIad67EDa+UqEKy/GltUwlSh6xy+TrK1tzDvAgMB AAGjggHMMIIByDAfBgNVHSMEGDAWgBQJwPL8C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQUzMeD Mcimo0oz8o1R1Nver3ZVpSkwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYB BQUHAgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9j cmwuc2VjdGlnby5jb20vU2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYoGCCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdv LmNvbS9TZWN0aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAj BggrBgEFBQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wHgYDVR0RBBcwFYETZHdtdzJAaW5m cmFkZWFkLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAyW6MUir5dm495teKqAQjDJwuFCi35h4xgnQv Q/fzPXmtR9t54rpmI2TfyvcKgOXpqa7BGXNFfh1JsqexVkIqZP9uWB2J+uVMD+XZEs/KYNNX2PvI lSPrzIB4Z2wyIGQpaPLlYflrrVFKv9CjT2zdqvy2maK7HKOQRt3BiJbVG5lRiwbbygldcALEV9Ch WFfgSXvrWDZspnU3Gjw/rMHrGnqlHtlyebp3pf3fSS9kzQ1FVtVIDrL6eqhTwJxe+pXSMMqFiN0w hpBtXdyDjzBtQTaZJ7zTT/vlehc/tDuqZwGHm/YJy883Ll+GP3NvOkgaRGWEuYWJJ6hFCkXYjyR9 IzGCBMcwggTDAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMT NVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA xr4ZlmdAxAMdKFES+jupfjANBglghkgBZQMEAgEFAKCCAeswGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMjQwMjAxMTcxODQwWjAvBgkqhkiG9w0BCQQxIgQg2zS68SBP FwBC9hLRhAbc2pPgDSz+KkiikomWclfpe4Ewgb0GCSsGAQQBgjcQBDGBrzCBrDCBljELMAkGA1UE BhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYG A1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAMa+GZZnQMQDHShREvo7qX4wgb8GCyqGSIb3 DQEJEAILMYGvoIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNl Y3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAxr4Z lmdAxAMdKFES+jupfjANBgkqhkiG9w0BAQEFAASCAgAm7sjBKVr7pvaQw8DnxjMwOVYu1tpMm2jA KFEIXr2VYtaBsptTS4w+uQRYXFW4QhdlHUuMfcysouEVrnF3om+HPRZgsVhzcuz+IyAHoMGIu5ch vl6/nu806VbKs/xr4j4LK/w9biQn+BYJd+K7Zcepfp+ExUk+ftiv6FcT8iwRkjL/FB3INutIZ4X5 Gz2N0IMzHId3IBZ9+iI0o7Y3rSjW1fkLm/1ponOza6Qp4j7znMVia76Xsdzh0grPjL7AyX0omFvt mihhruLRcCryQY5a6oeYDqgHQFwGqc8PRvMVMc9V8aLTTqd7iolaFoQZGujhKC/MVTSR3TCzSLfW DsZ03aCCKJzf7A1lOhVvRVPin+bDmVlBAFmgC1mENokIAzaNSQB+7tL/XcmmY1f/i9l7C1bZm0NQ T8S9YcYdjS3H7q9pgQOEukZNmf8cYGuYgHanhbg3+ZHTbQEKqroTheRgvsufot/NdNaUbVpl12PS 3ijDIf/Pd6y+x4/CJODE2KQi5dzPllXRSGV23QHUmMys/hkVLi8m8J6IfuFrjvbc9HDb3JJzCpQL rL90JBYeHI0yIPZ/g/A1oPUYK04lTQD/py0kv4fRcsZbhGLVN0BlMGD2j9jySEFnnzRYeGwOJNIZ MF8JcHBfDDC01fwWuOyds2lM+i2VxNn7/a2XJeuCDQAAAAAAAA== --=-I6Mgn+WqVKlm+Jzmgs0k-- From xen-devel-bounces@lists.xenproject.org Thu Feb 01 17:36:31 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 17:36:31 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674612.1049683 (Exim 4.92) (envelope-from ) id 1rVaz6-0002av-Hz; Thu, 01 Feb 2024 17:36:20 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674612.1049683; Thu, 01 Feb 2024 17:36: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 1rVaz6-0002ao-FL; Thu, 01 Feb 2024 17:36:20 +0000 Received: by outflank-mailman (input) for mailman id 674612; Thu, 01 Feb 2024 17:36:19 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVaz5-0002ai-8B for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 17:36:19 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVaz4-00061F-QR; Thu, 01 Feb 2024 17:36:18 +0000 Received: from [15.248.2.31] (helo=[10.24.67.35]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rVaz4-0005vb-Hi; Thu, 01 Feb 2024 17:36: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=zsnw957Hfwirsjx1xy39SSyh4Kw8IBkEQYb1cspkB/c=; b=FX7P5C9pdrgsi43y/iDae+DJJC mmM2UGQmE7hOuwHFuSTgD2wV1ZRhXtvbITAApdR/BMd+dwVa/pGPptoEZ4vcSqGMmSIucUWP5Upre tET1nn5xwTFggQPLuLiYeqrwGKRIFlOJGQNJew0dmlJ3vDZ1CcKZuNsryYu8Cskxq55k=; Message-ID: Date: Thu, 1 Feb 2024 17:36:16 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] xen/arm: Properly clean update to init_ttbr and smp_up_cpu Content-Language: en-GB To: Bertrand Marquis Cc: Xen-devel , Julien Grall , Stefano Stabellini , Michal Orzel , Volodymyr Babchuk , Oleksandr Tyshchenko References: <20240130172942.52175-1-julien@xen.org> <0D96C966-8DC4-43C5-9F61-0C54A2DC796C@arm.com> From: Julien Grall In-Reply-To: <0D96C966-8DC4-43C5-9F61-0C54A2DC796C@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 31/01/2024 07:57, Bertrand Marquis wrote: >> On 30 Jan 2024, at 18:29, Julien Grall wrote: >> >> From: Julien Grall >> >> Recent rework to the secondary boot code modified how init_ttbr and >> smp_up_cpu are accessed. Rather than directly accessing them, we >> are using a pointer to them. >> >> The helper clean_dcache() is expected to take the variable in parameter >> and then clean its content. As we now pass a pointer to the variable, >> we will clean the area storing the address rather than the content itself. >> >> Switch to use clean_dcache_va_range() to avoid casting the pointer. >> >> Fixes: a5ed59e62c6f ("arm/mmu: Move init_ttbr to a new section .data.idmap") >> Fixes: 9a5114074b04 ("arm/smpboot: Move smp_up_cpu to a new section .data.idmap) >> >> Reported-by: Oleksandr Tyshchenko >> Signed-off-by: Julien Grall > > Reviewed-by: Bertrand Marquis Committed. Thanks. Cheers, -- Julien Grall From xen-devel-bounces@lists.xenproject.org Thu Feb 01 18:28:06 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 18:28:06 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674663.1049721 (Exim 4.92) (envelope-from ) id 1rVbn0-0008RD-JO; Thu, 01 Feb 2024 18:27:54 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674663.1049721; Thu, 01 Feb 2024 18:27: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 1rVbn0-0008R6-Fp; Thu, 01 Feb 2024 18:27:54 +0000 Received: by outflank-mailman (input) for mailman id 674663; Thu, 01 Feb 2024 18:27:53 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rVbmz-0008Qw-Qu; Thu, 01 Feb 2024 18:27: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 1rVbmz-00078j-PR; Thu, 01 Feb 2024 18:27: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 1rVbmz-0006e4-E2; Thu, 01 Feb 2024 18:27:53 +0000 Received: from osstest by osstest.test-lab.xenproject.org with local (Exim 4.92) (envelope-from ) id 1rVbmz-0005P9-DU; Thu, 01 Feb 2024 18:27: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=rX8rLPavRS3L2XzwXivWDx/dMB/0BrCwqoH/MmpsE38=; b=2ZIej4vtwD6sCFLeRJy2TSushi pc8iZXHYlIW0rZWysaoUqB1PhgDIuTBMmXmoHJFceJQyu8REFJyaXQVQpfsEeaGWPCK/SOMaIn3FL 1E9RipsOrCBpLYKF3pIbnNLWZjsNkbUmjNVh6J/Dpvwxm6ZI0WGvr+/NlvYfzotpK+Ls=; 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] 184552: 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=bc45f20c01f1711bc56a4bb0955c49c182a5a03a X-Osstest-Versions-That: xen=cc6ba68edf6dcd18c3865e7d7c0f1ed822796426 From: osstest service owner Date: Thu, 01 Feb 2024 18:27:53 +0000 flight 184552 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/184552/ 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 bc45f20c01f1711bc56a4bb0955c49c182a5a03a baseline version: xen cc6ba68edf6dcd18c3865e7d7c0f1ed822796426 Last test of basis 184528 2024-01-30 14:03:48 Z 2 days Testing same since 184552 2024-02-01 16:00:25 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper Carlo Nonato Jan Beulich Jason Andryuk 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 cc6ba68edf..bc45f20c01 bc45f20c01f1711bc56a4bb0955c49c182a5a03a -> smoke From xen-devel-bounces@lists.xenproject.org Thu Feb 01 18:30:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 18:30:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674668.1049730 (Exim 4.92) (envelope-from ) id 1rVbpf-00020y-VV; Thu, 01 Feb 2024 18:30:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674668.1049730; Thu, 01 Feb 2024 18: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 1rVbpf-00020r-Sq; Thu, 01 Feb 2024 18:30:39 +0000 Received: by outflank-mailman (input) for mailman id 674668; Thu, 01 Feb 2024 18: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 1rVbpe-00020T-ST for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 18:30:38 +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 fe426915-c12f-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 19:30:37 +0100 (CET) Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-59a8b9b327aso588674eaf.2 for ; Thu, 01 Feb 2024 10:30:37 -0800 (PST) Received: from pm2-ws13.praxislan02.com (207-172-141-204.s8906.c3-0.slvr-cbr1.lnh-slvr.md.cable.rcncustomer.com. [207.172.141.204]) by smtp.gmail.com with ESMTPSA id pf8-20020a056214498800b0068c75141e73sm25824qvb.2.2024.02.01.10.30.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 10:30: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: fe426915-c12f-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706812235; x=1707417035; 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=vJji4XqXHiQq6UqkyTBADvfuoJ+3mi3CXw1t6K2EPpo=; b=CfKu3gHMrURnR5VmyAQeZ5dRpF06sIEGjmVfRwShbWJIMWJ1Th3IiVACbKlRYPTF6R 1fT78Nt0dAkQs3tY4VscgMIzNl0qoxZRTSP/1Xp8csxzlUdTy5pA1/nUkuJ294bDfuCn s2+SzMhYwHu3DQQxhsPVXfMoY/7NpC7Jjwa7YLh9JJJtf9LzryxiLAQCpkkA12GCu2tV hv/15wqGQ9jnwqRgQrJQE+3zqF5NBhYbnUiFtmO2oezEELeEaleyL+2VUQZ/XYQW8v4C n+sQbzbe/3HbTi1T4kvu7cbp+swVMCXHeKJsy25HLxxo44deqvXZ30eE5LBQfqeeQYWU ekCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706812235; x=1707417035; 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=vJji4XqXHiQq6UqkyTBADvfuoJ+3mi3CXw1t6K2EPpo=; b=qWOHlCCOcFGf+qm8GvdvU+KyISmrEneHBvWfyh1WCJQ052/zlXUng0WowT6VNkCtT+ lLv5Q1utJ7/956nGUJyAbLyS93QEreMVuL2HBMyrpIu7hlXwmpM1pKUcPSEx9cPFQr7M I7ztJ1Yftb1JWC0hG+yRIfrqPlEI+inhgcyTa9Y9nQ7oolpOw0ph2r2DrbS2OX1yj6FX MyvdEre0pQ8NmOFekBIKeGikTLKwwYz21VFvtOlay/vXNS47xECffYjufxBjC3nqsAat PntEmcuogsNwCxJYpR2i5X9lJI60FtrPeNl5M3CWBZ801y3xzGhnw3RakfsaVYGGNVOH yuHw== X-Gm-Message-State: AOJu0YyL6UVFs/PH7/kTcR9m81xd5Yu18+rYwvmRa2AX2cLSdbNBbqzW 6EA2m52TZU8BzdM3GmgZIUxkIhebsu5EocNeiN9FhSVX4CblOREMZdtrl1ij X-Google-Smtp-Source: AGHT+IGV0uyPo9vT0Nu0foAi8DR32p22Pp8jVZK9AlB4genAWqSBAP0FPq2wS6ruxXJ0fQURhtfBsg== X-Received: by 2002:a05:6358:4b05:b0:175:fc1a:c7df with SMTP id kr5-20020a0563584b0500b00175fc1ac7dfmr5911393rwc.15.1706812235109; Thu, 01 Feb 2024 10:30:35 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUHWpEq/EQiJKqWpN75DGqRJxbJeZ11a8UUSu3X/895bYo+YOko02W7JF9qji9NNesW7KkyvNP51IZNKtxVjIunowdVDL0aXFSem43458xbgSa4FEGGUuvCbTcQWtdIXHcrAb7vpWA= From: Jason Andryuk To: xen-devel@lists.xenproject.org Cc: Jason Andryuk , Wei Liu , Anthony PERARD , Juergen Gross Subject: [PATCH 0/4] libxl: blktap/tapback support Date: Thu, 1 Feb 2024 13:30:20 -0500 Message-ID: <20240201183024.145424-1-jandryuk@gmail.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patch re-introduces blktap support to libxl. Unlike earlier versions, it does not link against any blktap library. libxl changes are needed to write to the vbd3 backend XenStore nodes. blktap has three components. tapdisk is a daemon implementing the disk IO, NBD (Network Block Device), and Xen PV interfaces. tap-ctl is a tool to control tapdisks - creating, starting, stopping and freeing. tapback manages the XenStore operations and instructs tapdisk to connect. It is notable that tapdisk performs the grant and event channel ops, but doesn't interact with XenStore. tapback performs XenStore operations and notifies tapdisks of values and changes. The flow is: libxl writes to the "vbd3" XenStore nodes and runs the block-tap script. The block-tap script runs tap-ctl to create a tapdisk instance as the physical device. tapback then sees the tapdisk and instructs the tapdisk to connect up the PV blkif interface. This is expected to work without the kernel blktap driver, so the block-tap script is modified accordingly to write the UNIX NBD path. (It works with the kernel blktap driver as well - upstream blktap hasn't removed the blktap driver requirement yet - https://github.com/xapi-project/blktap/pull/364) An example command to attach a vhd: xl block-attach vm 'vdev=xvdf,backendtype=tap,format=vhd,target=/srv/target.vhd' VHD support is important for OpenXT since there are lots of existing VHDs which still need supporting. tapdisk also supports encrypted VHDs which is not available in QEMU. blktap's tapback needs minimal changes to work with libxl: https://github.com/xapi-project/blktap/pull/394 Jason Andryuk (4): block-common: Fix same_vm for no targets libxl: Add support for blktap vbd3 hotplug: Update block-tap libxl: Support blktap with HVM device model docs/man/xl-disk-configuration.5.pod.in | 4 +- tools/hotplug/Linux/block-common.sh | 8 +- tools/hotplug/Linux/block-tap | 162 ++++++++++++++++++++-- tools/libs/light/libxl_device.c | 14 +- tools/libs/light/libxl_disk.c | 37 +++-- tools/libs/light/libxl_dm.c | 1 - tools/libs/light/libxl_linux.c | 1 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c | 2 + 9 files changed, 201 insertions(+), 29 deletions(-) -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 18:30:41 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 18:30:41 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674669.1049740 (Exim 4.92) (envelope-from ) id 1rVbph-0002Fe-6I; Thu, 01 Feb 2024 18:30:41 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674669.1049740; Thu, 01 Feb 2024 18:30: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 1rVbph-0002FV-3R; Thu, 01 Feb 2024 18:30:41 +0000 Received: by outflank-mailman (input) for mailman id 674669; Thu, 01 Feb 2024 18:30: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 1rVbpg-00020T-Im for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 18:30:40 +0000 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [2607:f8b0:4864:20::f32]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id ffd0bc85-c12f-11ee-8a43-1f161083a0e0; Thu, 01 Feb 2024 19:30:40 +0100 (CET) Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-6818a9fe380so7291216d6.2 for ; Thu, 01 Feb 2024 10:30:40 -0800 (PST) Received: from pm2-ws13.praxislan02.com (207-172-141-204.s8906.c3-0.slvr-cbr1.lnh-slvr.md.cable.rcncustomer.com. [207.172.141.204]) by smtp.gmail.com with ESMTPSA id pf8-20020a056214498800b0068c75141e73sm25824qvb.2.2024.02.01.10.30.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 10:30: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: ffd0bc85-c12f-11ee-8a43-1f161083a0e0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706812238; x=1707417038; 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=+F33WLb8SsbhR8svkMBYfGDsCEmngZ8q/7ZaljEVS3M=; b=UwPIDUq10isCpumWgi97FEc+KPHMV/lzjQUdUJom8FKLNOJFrxvg3FpDxy5n1gp0SE ILP/i+JESIXyEntN9bZ7ZnT0kSF9Lghvd2zwS+Ry47cSDo81pHYekxtpC4VRgBVOFAK/ a1Yld2ffKmAMfgyouFIDep2M93QDSeBunhSO4rlgMxWgc3obZ0v6hJoL3n1Xv7GSDkMi OPccFDprcDcMguOjOwAyltWBf8EWXT58S4poeFpQKBBALojtDoGsdS2+p8gToes8vzkC uPGaBEHFBmakozTIu8ss+w5px7ICfrjYndxV+xBhNnPn2AQScBW7p7OEV2VSRyJHvWF4 S6tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706812238; x=1707417038; 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=+F33WLb8SsbhR8svkMBYfGDsCEmngZ8q/7ZaljEVS3M=; b=u0KzJ0SFsLvWzqhs/El9QLGfcKEqRfX3qbSny+BaEjNoJdGm3O6rFscApUIUTrpQzg W6G5pQPE6ih1PCBMbbVG/K/gvZT67NSCah02mii74/K2cP4Pn1Vq9zpm3lXgq+gyCSAG XPT+z45wV1qjxAu0suGPhimK1LBdPDCB3DRcHFC3M4loetB6+/5KfsDfdG8FSGQ7uZoT 8cEfIPWkkk+BUwrX29FLYmXHB6X8bSyzUky0xN5IBYJTLxpum/KtzPWWzNTFJCYyO6PF HgSfdW8teWeWgdW77qbHMfiuaUTc9vUyG/kXH3eKcwC0FMt+KjUJ3EzdUfqYKwaRF8Gs 3Ahw== X-Gm-Message-State: AOJu0YygHjLqaUkQdraYAfzk38lBy+7c1hE0yaC5XANj1aZlbcEJKohG 3rdjr2+ZCagm4bTxfzDClSljNQ3KCgQtJzOsaqj3mGIhsikuCBauWSv//0im X-Google-Smtp-Source: AGHT+IEShpw6JudIZoJMi92UdXTK/nz8GoPmUq8wT+imB1lMTJxLIqgl6uF2XZHxabDNwONIF0UnIA== X-Received: by 2002:ad4:5746:0:b0:686:a472:1205 with SMTP id q6-20020ad45746000000b00686a4721205mr6139692qvx.0.1706812238079; Thu, 01 Feb 2024 10:30:38 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCVCqkg7ZSjgpD/6/3COlNsVpzNskT++aPAlEYlQcK/J6/X50n8ZfzMbMgXQu2IqIT3VJLJ2pWTsNJ/JK/rhpjASjcHk5PBWTPpYhRO3amEmvhZkTGv+ From: Jason Andryuk To: xen-devel@lists.xenproject.org Cc: Jason Andryuk , Wei Liu , Anthony PERARD Subject: [PATCH 1/4] block-common: Fix same_vm for no targets Date: Thu, 1 Feb 2024 13:30:21 -0500 Message-ID: <20240201183024.145424-2-jandryuk@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201183024.145424-1-jandryuk@gmail.com> References: <20240201183024.145424-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit same_vm is broken when the two main domains do not have targets. otvm and targetvm are both missing, which means they get set to -1 and then converted to empty strings: ++10697+ local targetvm=-1 ++10697+ local otvm=-1 ++10697+ otvm= ++10697+ othervm=/vm/cc97bc2f-3a91-43f7-8fbc-4cb92f90b4e4 ++10697+ targetvm= ++10697+ local frontend_uuid=/vm/844dea4e-44f8-4e3e-8145-325132a31ca5 The final comparison returns true since the two empty strings match: ++10697+ '[' /vm/844dea4e-44f8-4e3e-8145-325132a31ca5 = /vm/cc97bc2f-3a91-43f7-8fbc-4cb92f90b4e4 -o '' = /vm/cc97bc2f-3a91-43f7-8fbc-4cb92f90b4e4 -o /vm/844dea4e-44f8-4e3e-8145-325132a31ca5 = '' -o '' = '' ']' Replace -1 with distinct strings indicating the lack of a value and remove the collescing to empty stings. The strings themselves will no longer match, and that is correct. ++12364+ '[' /vm/844dea4e-44f8-4e3e-8145-325132a31ca5 = /vm/cc97bc2f-3a91-43f7-8fbc-4cb92f90b4e4 -o 'No target' = /vm/cc97bc2f-3a91-43f7-8fbc-4cb92f90b4e4 -o /vm/844dea4e-44f8-4e3e-8145-325132a31ca5 = 'No other target' -o 'No target' = 'No other target' ']' Signed-off-by: Jason Andryuk --- tools/hotplug/Linux/block-common.sh | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tools/hotplug/Linux/block-common.sh b/tools/hotplug/Linux/block-common.sh index f86a88c4eb..5c80237d99 100644 --- a/tools/hotplug/Linux/block-common.sh +++ b/tools/hotplug/Linux/block-common.sh @@ -112,14 +112,12 @@ same_vm() "$FRONTEND_UUID") local target=$(xenstore_read_default "/local/domain/$FRONTEND_ID/target" \ "-1") - local targetvm=$(xenstore_read_default "/local/domain/$target/vm" "-1") + local targetvm=$(xenstore_read_default "/local/domain/$target/vm" "No Target") local otarget=$(xenstore_read_default "/local/domain/$otherdom/target" \ "-1") local otvm=$(xenstore_read_default "/local/domain/$otarget/vm" \ - "-1") - otvm=${otvm%-1} - othervm=${othervm%-1} - targetvm=${targetvm%-1} + "No Other Target") + local frontend_uuid=${FRONTEND_UUID%-1} [ "$frontend_uuid" = "$othervm" -o "$targetvm" = "$othervm" -o \ -- 2.43.0 From xen-devel-bounces@lists.xenproject.org Thu Feb 01 18:30:46 2024 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 01 Feb 2024 18:30:46 +0000 Received: from list by lists.xenproject.org with outflank-mailman.674670.1049750 (Exim 4.92) (envelope-from ) id 1rVbpm-0002Xv-Du; Thu, 01 Feb 2024 18:30:46 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 674670.1049750; Thu, 01 Feb 2024 18:30: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 1rVbpm-0002Xm-Al; Thu, 01 Feb 2024 18:30:46 +0000 Received: by outflank-mailman (input) for mailman id 674670; Thu, 01 Feb 2024 18:30: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 1rVbpl-0002Wb-2Q for xen-devel@lists.xenproject.org; Thu, 01 Feb 2024 18:30:45 +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 017bb2e7-c130-11ee-98f5-efadbce2ee36; Thu, 01 Feb 2024 19:30:42 +0100 (CET) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-783d8e09a1cso73034085a.3 for ; Thu, 01 Feb 2024 10:30:42 -0800 (PST) Received: from pm2-ws13.praxislan02.com (207-172-141-204.s8906.c3-0.slvr-cbr1.lnh-slvr.md.cable.rcncustomer.com. [207.172.141.204]) by smtp.gmail.com with ESMTPSA id pf8-20020a056214498800b0068c75141e73sm25824qvb.2.2024.02.01.10.30.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Feb 2024 10:30: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: 017bb2e7-c130-11ee-98f5-efadbce2ee36 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706812241; x=1707417041; 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=PjjeoKX1m7W13o8Y7ZaEmX1lMzcVrUhBaLtbtuWZOxs=; b=WIQ8by9wMw2KvMGH49gSyXd36QEqZQA622acQ002jIMFMIxVWuGZul50oDt7i5ScWX VGBX8r3MhGIaeVc6xObwGA/QW+RORrZD9kH2tI7O+ujnhC9wZzu1BqQMBaPV0VHWEVlb hF5iTcRLKum26F2Qj6HhKkqsJf0v79pPU+9V48t/KcBMy2SlGUYKCKKoPOWJbXxRmZMZ v77EMJtgugJ0+G9Qd4aH8H5403vFnAXf/mNE5ahd8gINEbJ42b21gq4WEkpI7nkIi3aj SS0y37/8HIay1vvm2sEaAWPJ4c6tzXWR+4gnta7HyJE1tLGxJjRkNJcYvACCPh8LA/74 EF+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706812241; x=1707417041; 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=PjjeoKX1m7W13o8Y7ZaEmX1lMzcVrUhBaLtbtuWZOxs=; b=LgMm/hph4edgBqGNgiJnXrh9mdiOpUFAJcWLUbieDmZbCsoDUKBQa/+Iu/yojkN9nw M2BLVh7RXypRDDoWUnTQ2dlJZFmm+gMDf20iwvfgI2BylIc/qdsAKIuYsecLMNCjjhxO ip+H95wwFFhgRgnEgBvP27LHzwvxAb796hfiHBWHgv06QSR+/J8HBRjOXMpOzsW7LTKr cafheP6xhrP5CHgJX4ek3Ysoo0/J77Mzw0Vcq6950MF83GOpl1EvbxOoYs2H/lQW5U2o FNR1qW24WI9ESyFaLfrLY4qubAc7ImTkCNXz4IDwEfWnPq6jf4ceJD0LNOCM8bmfOlwE PG8g== X-Gm-Message-State: AOJu0YxuhG1zHXVPq4o3Dcyk3AGkGDmg3WxkRUwoGOSz04gPJvUy/FhZ N94oPdX7qO9Nceh/KFNazy3QbvGzhXQ4h/lZttweBuJ1U5nTVb61jVQyqDGC X-Google-Smtp-Source: AGHT+IFHvs1BSlxFAbLomRF+WK4BCyWVl6PudvCCCdULyTh8v4FtjY//z2fGun7qgHHPllbSX1rsxg== X-Received: by 2002:ad4:4ea4:0:b0:68c:61bd:7765 with SMTP id ed4-20020ad44ea4000000b0068c61bd7765mr6903583qvb.45.1706812240849; Thu, 01 Feb 2024 10:30:40 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCUYh1WG/ROL1iDB4lPXW50gxnr9Y/V7AJ3B0CY7+Ub0PhR7RfgTo5nnJIcli8/j7t8CiihQDJFiPSft5ZniYYiK7NPm1J2tGxvtsXgRUsFt6+hfcP8Zy4Ivq4HcVhDdMpnJHprtF7g= From: Jason Andryuk To: xen-devel@lists.xenproject.org Cc: Jason Andryuk , Wei Liu , Anthony PERARD , Juergen Gross Subject: [PATCH 2/4] libxl: Add support for blktap vbd3 Date: Thu, 1 Feb 2024 13:30:22 -0500 Message-ID: <20240201183024.145424-3-jandryuk@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240201183024.145424-1-jandryuk@gmail.com> References: <20240201183024.145424-1-jandryuk@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patch re-introduces blktap support to libxl. Unlike earlier versions, it does not link against any blktap library. libxl changes are needed to write to the vbd3 backend XenStore nodes. blktap has three components. tapdisk is a daemon implementing the disk IO, NBD (Network Block Device), and Xen PV interfaces. tap-ctl is a tool to control tapdisks - creating, starting, stopping and freeing. tapback manages the XenStore operations and instructs tapdisk to connect. It is notable that tapdisk performs the grant and event channel ops, but doesn't interact with XenStore. tapback performs XenStore operations and notifies tapdisks of values and changes. The flow is: libxl writes to the "vbd3" XenStore nodes and runs the block-tap script. The block-tap script runs tap-ctl to create a tapdisk instance as the physical device. tapback then sees the tapdisk and instructs the tapdisk to connect up the PV blkif interface. This is expected to work without the kernel blktap driver, so the block-tap script is modified accordingly to write the UNIX NBD path. backendtype=tap was not fully removed previously, but it would never succeed since it would hit the hardcoded error in disk_try_backend(). It is reused now. An example command to attach a vhd: xl block-attach vm 'vdev=xvdf,backendtype=tap,format=vhd,target=/srv/target.vhd' Format raw also works to run an "aio:" tapdisk. Signed-off-by: Jason Andryuk --- VHD support is important for OpenXT since there are lots of existing VHDs which still need supporting. tapdisk also supports encrypting VHDs which is not available in QEMU. --- docs/man/xl-disk-configuration.5.pod.in | 4 +++- tools/libs/light/libxl_device.c | 14 ++++++++++---- tools/libs/light/libxl_disk.c | 20 +++++++++++++++----- tools/libs/light/libxl_linux.c | 1 + tools/libs/light/libxl_types_internal.idl | 1 + tools/libs/light/libxl_utils.c | 2 ++ 6 files changed, 32 insertions(+), 10 deletions(-) diff --git a/docs/man/xl-disk-configuration.5.pod.in b/docs/man/xl-disk-configuration.5.pod.in index bc945cc517..cb442bd5b4 100644 --- a/docs/man/xl-disk-configuration.5.pod.in +++ b/docs/man/xl-disk-configuration.5.pod.in @@ -232,7 +232,7 @@ Specifies the backend implementation to use =item Supported values -phy, qdisk, standalone +phy, qdisk, standalone, tap =item Mandatory @@ -254,6 +254,8 @@ and "standalone" does not support specifications other than "virtio". Normally this option should not be specified, in which case libxl will automatically determine the most suitable backend. +"tap" needs blktap's tapback to be running. + =item B